The C4 Engine
July 14, 2008 – 10:06 amDuring the last 20 weeks (February to June ‘08), I and 7 other people have been working on a game project (both for university points and for this online group of dudes that started the creation of this particular game), 2 of them programmers, 5 of them artsy fags media students (who did models, textures, sketches, sound/music etc).
The game itself is a sci-fi tactical first person shooter (well, it’s supposed to be in a distant future, olz), which was basically in a half-assed concept stage for about a year or two, during which some very nice concept art drawings were made, but nothing concrete was made, such as actual game design (i.e. functional design) or background story.
The project was eventually put forward to our university as a project for the Game Design minor, and since then, we’ve been working on it for the last 20 weeks. In this post, I won’t go into detail about the project itself, but more into the 3D engine that was used: The C4 engine.
About
The C4 Engine is written and maintained by Eric Lengyel, a mathematician slash application developer, who’s worked on the technologies behind several games, including several PS3 titles (although no actual names are given). He’s also written some or contributed to some books, including Mathematics for 3D Game Programming And Computer Graphics, so he bascially knows what he’s talking about.
C4’s got a load of features, including all the basic graphics capabilities one would want for a game, as well as a built-in world editor, graphical script editor, etc. The next version, 149, which is out now for licensed users, has a greatly improved graphical script editor, with conditionals and variables and whatnot (it didn’t have those earlier). Version 1.5, to be released late August if everything’s right, will come with a terrain editor and large outdoor terrain support (as in, the current version is mainly suitable for indoor or ‘roomed’ environments, which can be divided into so-called zones, which are used to determine what has to be rendered etc).
For more info on C4’s features, look here.
The C4 engine is aimed at both professional users and ‘indie’ game developers (independent, hobbyists, students etc). For both types, a license can be aquired. The indie category, such as we are, can get a license for as low as $200.-, which gives the licensee a lifetime license (= free updates to later versions), and allows 5 people to work on the engine and the engine’s code. However, this license type will be updated when version 1.5 (150) is released, and will be upped to $350,- accoring to the C4 website. The engine is supplied as both the executables, plugins and, something unique, the full source code to both the engine and the demo game. That means that programmers can edit or add features to the engine itself, and get a deeper insight into the workings of the engine by reading its code. According to the C4 engine’s website, some large corporations (such as Lockheed Martin) and universities have taken licenses for the C4 engine.
Screenshots
Let’s goan see some screenshots from the current demo game which, by the way, doesn’t show off the full potential of the demo game. The full-sized screenshots can be viewed here.
This first image shows a basic piece of a level with a so-called cube light, a light that basically projects a texture 360 degrees around it. In this case, it projects the insides of a lantern.
This next image displays a scene from the Cemetery level, a relatively new demo level. This particular screenshot displays an imported terrain (not using the terrain editor yet btw, just the height map import option), with a fog layer on top of it. The fog’s fully configureable, so you can set the height at which it starts, the color, the density, etc.
A feature not shown in this screenshot is the lightning effect, which lights up the entire level and plays thunder sounds and such. Once again, this isn’t a level that’s graphically the most impressive, just a limited feature showcase - see some of the screenshots for other games made with C4 for better examples.
The Ravensword game screenshots shows how good proper normal maps can look (normal map is a texture that contains height information, which is used to calculate shadows on the object itself, which translates to a perception of depth and detail). The screenshots for World of Subways (yes, a subway simulator game) look in roughly the same style as Half-Life 2, only more realistic (and with less zombies).
The above screenshot is taken from the primary demo level, and shows imported terrain for the overall layout of the land, a waterfall effect (made with C4’s particle system), water itself (which uses animated textures and portals for reflection / refraction, see also this tutorial on C4’s wiki on how the water effect was made.) , etcetera.
This next screenshot is of C4’s built-in world editor, which allows people to make their own worlds. On the left side is a menu bar, which contains all the tools a world editor can use. The pane next to that is the Scene Graph, a graphical representation of the internal structure of a world editor. A root node, the Infinite Zone, contains a handful of subnodes, such as geometries, light sources, etcetera, which in turn can contain several subnodes as well.
The above is a screenshot of C4’s graphical script editor, I’m fairly sure this is the old (or current) version. Version 149 of the engine, to be released soon, contains additional features that could, once fully developed, allow non-programmers to program the behavior of an NPC, for example.
Experiences
Anyways, this was supposed to be more of a review and experiences with the C4 engine, but eh, it’ll need a good intro in order for people to sorta know what we’re talking about.
We’ve spent a good 20 weeks on our project, half of which was spent designing our game and exploring the C4 engine. We played around and made some basic worlds with the world editor, dived into the demo game’s code and edited some stuff, added a weapon by following a tutorial, etcetera.
It was pretty daunting to begin with for several reasons:
- A new language. Up until this project, all 3 of us (we had 3 programmers in our group) had little to no experience programming in C++ - I myself had done a fractal generator largely copied from the internets during a 2-week period. So with the C4 engine (which is written in C++, in case you didn’t realize that by now), we encountered new, unexplored problems like pointers and such. Scary.
- A new environment. The C4 engine’s quite different from the Java libraries and such I’ve used before this, with a lot of tricks and such. For example, a lot of binary flags are used - basically a means of storing a large amount of boolean data into a single variable. But that was all learnable.
- Poorly designed demo game. The engine itself is designed properly, but the demo game’s code looks as if it was programmed in some free saturday afternoons. There’s 500-lined functions containing large switch-statements which contain logic for pretty much all components for the demo game, to name an example. More on that later.
- Lack of commenting / documentation. The C4 engine’s code itself is reasonably documented (it’s not entirely complete and in a format that basically forces you to view the online version), but the demo game itself isn’t. There are some scarce one or two-lined comments in particular bits of code, but not by far complete. So in order to understand the inner workings of the demo game, we had to dive into the code itself and work according to some of the tutorials on the C4 wiki. But after some time, we got the hang of it and knew enough of both the engine and the demo game’s code to add most of the features we wanted.
We added our own weapons (a handgun and an assault rifle), some of our own models (not all, which is why we didn’t get all the points for the end-product), animations (and animation control), sounds, and our own special features - distraction grenades, one that generated a ‘hologram’, one that played a sound, and one that displayed a flashing light pattern (which is supposed to look like gunfire). All three configureable by the player (by using an in-game selection menu), etc. They were all fired by the C4 demo game’s grenade launcher, but it’s the idea that counts.
We also added teams to the players (a multiplayer mode was already available), 3 game modes, and did some refactorings by splitting up some of the classes into their own files (a habit from Java, counteracted by the habit of whoever wrote the demo game to put loads of similar classes into a single file). The end result was a game that displayed most of the features we had planned, but didn’t look as good and looked basically only half-finished, due to the lack of models and the levels being only half-finished. But I myself got most points, mainly due to programming.
Anyways, the C4 engine left a very good overall impression on me. I haven’t had any experience with other game engines (that is, unless you count ZZT as being a game engine), but those that do think that C4’s the most awesome and well thought-out engines they’ve encountered so far. The engine itself is very rich in features without looking cluttered or bloated, and is still in full development, a new version with new features being released every month or so. We started when the engine was at version 147, and when we were done, version 149 beta 2 was out. A few days ago, the final version of 149 was released, along with a new demo including new demo levels and everything.
Criticisms
The majority of criticisms we as programmers had on the engine was all in its demo game and the documentation. The code-level documentation is allright (see above), but in terms of ‘how do you do so-and-so’, it’s still lacking. For example, halfway our project I wanted to find out how the C4 networking system worked. At that time, the only documentation avaiable was an article on the C4 wiki, highlighting the basic assumptions and workings of the network and messaging system, and the API documentation itself on the messages and message manager, which sends and handles messages, as well as the network manager, which operates on a lower level.
So because of that, we were bascially forced to figure it all our on ourselves, mainly trying to get as much information as possible from the API documentation and the code found in the demo game. Because we didn’t want others to have the same problem (and spend as much time on solving it), we (read: I) wrote a two-part tutorial on C4’s messaging system, in which a basic chat application is made. You can find that tutorial right here, and part two here.
But yeah, not everything is as of yet documented and explained. There’s enough to get you going, but it’s just not all there yet.
The second major problem was the lack of design in the demo game. There’s at least a dozen examples to think of, but it’s kinda bollox to have to repeat them all here. I can do one example though, the weapon system in the demo game. According to the tutorial on the C4 wiki on adding a weapon to the demo game, a programmer has to add two files to the project, and edit 12 (!) files to add it to the game. These files handle firing, selecting, picking up, ammo etc of the weapon. But the problem is that it’s so divided, it’s difficult to figure all that out on your own without the use of a tutorial. Not only that, but the weapon system is decentralized, or, to put it more bluntly, all over the place. There are .h and .cpp files for each type of weapon, but they don’t contain anything related to the weapon itself, only to the projectile fired by the weapon (if any). Firing the weapon happens in a very large method in the Fighter class, a controller for the player’s model, which is called each frame, checks if a timer has run down to 0, then checks what weapon is currently selected, re-sets the timer and calls a function that informs everyone that a projectile has been fired, which in turn generates a projectile and moves it every frame.
But that’s not how you’d want things to happen. You’d want each weapon to have its own files, and its own responsibilities. You don’t want a fixed number somewhere in a very large method in the Fighter class to determine how fast a weapon fires, you want it to occur in the weapon’s file itself, and make it dynamic even if you think that’ll add something to your game or if you just want to tweak it.
And that’s just one example, there were at least 3 more specific modules of the demo game that were just designed… well, wrong. They worked fine, so functionally they were good, but their design was just awful (imo), everything was fixed at compile-time, loads of functionality was crammed into a single method, loads of responsibility into a single class, and so forth.
We didn’t have the time during our project to fix all this, so instead we (read: I) made a document in which the game’s modules are described, the problems occuring in those highlighted, and one or more solutions described and explained. I firstly put that up for assessment by the teachers (one for the techical design, the other for Written English), then offered it to the licensees and author of the C4 engine. So far, only two or three licensees have commented on it (both whom I doubt understand even half of what’s in there), and the author is yet to comment on it. He’s probably busy with the next version of the engine though, so I won’t blame him.
I’ve put the refactoring proposal online for your reading pleasure, maybe you can learn something from it. As I said on the forums when I posted it, any C&C on it is welcome. Here’s the file:
Office 2007 version: Refactoring Proposal
Office 1997-2003 version: Refactoring Proposal
It’s also an attempt at applying some design patterns, including the Composite, Visitor, Factory Method, and Prototype patterns. I’m sure that more patterns and refactorings can be applied to the demo game’s code, but the components described in the document should give a very good head start (if I say so myself, /smug). That, and if done right, could inspire others as well.
Currently, I’m finishing up on our project, and in order to get the last few points I’ve started to implement at least some of the refactorings proposed in the document into the C4 demo game, and publishing those refactorings on the forums. I probably won’t spend a lot of time on that anymore, since I haven’t had much feedback on the proposals, least of all from the author himself (i.e. the dude that actually matters). I even sent him a PM about the matter, but I’ve received no feedback whatsoever. Either he hasn’t gotten to it, or he’s just ignoring the whole thing - I’m suspecting the latter, and I don’t like it. But eh, it’s his product, and as such, his problem.
Conclusion
But, outside of the (in my opinion) poor design of the demo game, the C4 engine is pretty good. As said, I have no experience with other graphics engines, so I’m unable to provide a proper comparison, but from what I’ve seen of the C4 engine, its features, its relatively low price and all that, I’m impressed. It has pretty much everything anyone needs making a 3D video game, and the features it doesn’t have will be added in the coming versions. As I probably said in the beginning of this article, version 1.5 will add a terrain editor to the engine. I dunno how advanced it will be, but from what the author says about it, it’ll be technically quite impressive. (note that the author of the engine isn’t the first poster in the linked thread, but the dude with the red username etc).
All in all, I think that from a bang-for-buck point of view, the C4 engine is the best engine any beginning game developer can buy. For inexperienced or unmotivated programmers it may have a steep learning curve (mainly due to the poor design of the demo game - it’s all in there, but it’s hard to get it out), but it’ll be well worth it. I only wish the demo game had a better design, ’cause right now it’s putting people off. Not as much as they’ve been put off by other affordable engines (judging by some of the forum posts by previous users of said engines), but still.
2 Trackback(s)