Hey all, it’s been awhile since I’ve updated, so I figure I’d let you guys all in on my current project. I call it the FicEngine.
What is the FicEngine?
The FicEngine is a game engine developed independently by me, for use in my own independent game projects. In development for about a month now, the FicEngine is designed to be a robust toolset that I can use to quickly get game mechanics working and ideas rolling. It takes the basic concepts I laid down in Kill Dr. Cote, and later refined in Arachnoid: Predator of Worlds, adds to it the experience I’ve gleaned from my 18 month tour-de-force of working in the videogame industry.
The design philosophy of the FicEngine:
- Creation is the credo. Games are the goal. Over-engineering an engine is a sure-fire way to failure. My goal is not to make an engine. It’s to make games. The first rule of the FicEngine is that the FicEngine is only a means to an end. The end goal will always be the next awesome game that rocks your face. The FicEngine exists only as a central core of code that should only be written once.
- Speed and Agility are clutch. The FicEngine is designed to allow me to create games with incredible speed. By laying the foundation of classes that I use most often in a central core, I can create a game in a matter of hours. The goal is to be able to prototype an idea in under 10 man-hours, and it’s looking like I will achieve that with the FicEngine.
- This engine is designed by me, for me. Sounds selfish, but it’s a central idea that I need to keep in mind. One big thing I learned from my experiences as an indie smashing game-dev contests, and as a paid employee in both fairly large (50+ people) and small (15) game companies is that coders all have their style. When I chose to create the FicEngine instead of using an existing engine such as Torque or Unity, I chose so because with my own engine I can cater precisely to my style of coding, which will allow me to express myself much more easily. Programming is much like architecture, and I definitely fancy myself more of a Howard Roark than a Peter Keating. Also, in creating my own engine, I don’t have to cater to “the user.” The user is ME. I don’t intend to market the engine, like I said, it’s a means to an end, and a means only.
- Leverage existing tools and code. Don’t reinvent the wheel. Progress is taking everything you’ve learned so far, and using it to get to the next level. This is especially true in game development. Tons of people have solved so many problems already. We have sorting algorithms and efficient, reusable data structures, great tools and middleware– there’s no reason to reinvent all this. I’ve seen some people view OPC (other people’s code) as nothing short of the antichrist and insist that the only way to code something right is to code it yourself. What a waste of time and effort that could be spent making games! OPC is out there for a reason- it works, and solves an existing problem. So if it’s free to use, USE IT whenever possible!
- No limitations. Here’s another tough one. Limitations are a natural by-product of robustness, and this was also a major factor in not going with existing game engines such as Torque or Unity. The limitations in those engines, in my opinion, come about because those engines are also 3D graphics engines, as well as game engines. The FicEngine is all about separating the game logic from what you see on screen. In the FicEngine, you might see models and vehicles zooming around in 3D, but maybe in reality, all you need for the game logic are a few circles and rectangles. The LOGIC is central to the FicEngine.
Here’s a quick list of features of the FicEngine. I can go into more detail in later posts about each one, but here’s them in a nutshell:
- Excellent cross-platform potential. It is based off of all cross-platform libraries such as SDL and OpenGL, and is designed for maximum portability. It is being developed on a Mac, but compiles straight out of the box for Windows. SDL and OpenGL calls are encapsulated, to allow for fast (and one-time) portability to Xbox 360. The game logic is 100% cross platform- so port the engine once, and all the games go with it! Also planned is FicEngine Lite, which I guess you could also call FicEngineDS
- Robust asset management. This one is really nerdy, so I won’t go too much into it, but I can define any kind of asset I want, such as textures, sounds, music, shaders, or even made up stuff like xml definitions for user interfaces, and the FicEngine catalogs it for easy retrieval anywhere in the game.
- Support for modern 3D graphics. While it is not my primary goal to create a 3D engine, the FicEngine does support a programmable pipeline using shaders. In fact, FicEngine graphics are totally based off of shaders- this not only allows for the potential for very modern, cool graphics, but it also makes organizing the scenegraph much easier. But don’t think I’m going totally 3D either! The support is there, but there is also a sprite animation system that I plan on making great use of
- Incredibly robust input system. I’m proud of how this one turned out. All interaction with the game world is done through a set of game commands, and a game command can be mapped to any input on any device, whether that be a mouse, keyboard or joystick. Not only that, but the Xbox 360 controller is treated as a special case, since it’s probably the best controller I’ve used, and because there are just over 9 million Xbox 360 owners out there at the time of this blog post. So if you have your 360 sticks with you, you can plug them into your Mac or PC and feel right at home in a Justin Fic game.
- Lightweight, yet robust sound system. Using SDL_mixer, the FicEngine implements a simple yet robust positional sound system.
- Here’s my favorite at the moment: A robust, extendable system for defining bullets and guns. I call it “ARSENAL.” ARSENAL will allow me to create a huge variety of guns and ammunition using many different variables. Defining a new gun is as simple as laying out the parameters in an xml file- a process that takes at most 2-3 minutes. And the data driven approach means that testing guns in ARSENAL is extremely fast. I can even reload ARSENAL at any point in the game, so I can change a gun’s parameters on the fly and see its new behavior instantly. I definitely want to give ARSENAL its own blog post later on!
- A fiendishly simple physics/collision system. A tough decision that I made with the FicEngine was not going with an existing physics SDK to solve my physics needs. There are many good ones out there, but I decided that their limitations weren’t worth the trouble, that they didn’t jive with my style of coding, and frankly, physics is one aspect that I like coding myself. So all I have to do is register a game object with physics, and it moves. BAM. Register it with collision, give it a shape, and it hits stuff. BAM. Also unique to my system is the concept of factions. I borrowed the concept from Everquest and related MMOs, where certain factions are friendly or not so friendly to each other. Well in physics, all objects belong to a faction, and it only collides with certain other factions, which I can define.
- Extendable, data driven UI. The last 10 months of my game industry experience have been centered in Xbox 360 UI programming. In that time I have designed a set of classes that are reusable, extendable, and powerful. The only problem is that controlling a UI with a mouse is vastly different than controlling it with a 360 controller! So my improved UI system, which I call “FUI2″ uses the aforementioned concepts of game commands to control its UI elements, and can switch between Mouse and Paddle modes. (Mouse mode is also useful for control schemes such as a stylus or Wiimote.) It is also now data-driven, so you can lay out your UI in XML, and, like ARSENAL, you can reload it on the fly.
So that’s FicEngine in a (admittedly long) nutshell. I’ll detail the systems above soon, but the important thing to take away from this is that Justin Fic is back as an independent force to be reckoned with. Development on the engine will continue for the next 2-4 weeks, after which you will start seeing blog posts on game prototypes. I will keep you all posted on my progress via this blog, and maybe BDPE also whenever I can squeeze it in.
Later!