FicEngine: Graphics, Sprites, Pixellation
First, before this post, an announcement: Prototyping has begun. And by prototyping, I mean I’m making the next game. You’ll be hearing more about it as I move off from engine development to game design, which is an infinitely more creative and exciting process. Especially with the FicEngine taking a good solid month longer than I wanted it to, I thought I was going to go insane if I didn’t blow some shit up real soon. Now, that’s not to say I won’t return to the FicEngine, in fact, the very first game I want to make will require some improvements to ARSENAL (namely, the ability to level up guns, and the various parameters of guns, i.e. rate of fire, independently from one another.)
As for what the game is about, I’ll be revealing more and more of that as we go on. I just gave you guys a teaser, and I’m definitely writing the backstory as we go along.
In the meantime, this blog is a few posts behind my progress on the FicEngine. So this time, you’re getting a triple dose: Graphics, Sprites, and Pixellation. They’re all visual elements, and I’m behind like five posts, so screw it 
The graphics system in the FicEngine is a little different from most other engines. Actually, it’s very different. The FicEngine has no trace of a scenegraph whatsoever.
“But Fic,” you might say, “a scenegraph is absolutely vital to every engine!” And you’d be right. It is. And that’s the problem. What it comes down to is that a game engine is vastly different from a 3D graphics engine. I mostly blame the FPS genre for blurring the distinction between the two, but it’s the responsibility of devs behind smaller games to recognize the difference.
Instead of a scenegraph, the FicEngine uses a number of “soups” composed of many game objects. The hierarchical functionality of a scenegraph is handled, for the most part, by the game objects themselves, with other more costly things (texture/shader binding, render state changes) being handled by the renderer that contains the soups. It’s definitely a weird solution, and I’m not 100% on it yet (until I try it out on some games) but it handles rendering just fine, and it’s built around shaders, making it ready for OpenGL 3, and making it easier to port to Xbox360 in the future.
The second part of this post is Sprites. Sprites are basically 2D animated characters on the screen, and the FicEngine has a great system for loading, drawing, and animating them. As with all of the other systems, it’s data driven through XML, so adding a new sprite can be done in minutes. It’s pretty flexible, so I imagine I’ll be limited by artistic ability far before I’m limited by the code 
The final part of this triple-post is Pixellation. This is an effect that can be done with OpenGL’s framebuffer objects that can achieve a retro, pixellated effect. For an example of this, go find Cave Story and play it. It’s a modern game that emulates the smaller resolutions of 8- and 16-bit systems. Here’s an example from the engine:
Above is a snippet from a screenshot of Ground Zero, which is my test bed of sorts for the FicEngine. Pixellation is not enabled in this scene. Now, check it out:
Now, that obviously lacks the retro charm of Cave Story. In fact, it looks like ass. Enabling this effect in a regular 3D OpenGL scene will cause it to look more like Doom. Extra measures must be taken with the game logic to ensure that the graphics have that crisp, 8-bit look and feel. Luckily, I know what those are
With that, this blog is very nearly caught up to my actual progress. The final system that I want to talk about is the User Interface, and then we can put this boring engine-talk behind us and I can start showing you some games!
No comments yet.
