Category FPEngine

Architecture Improvements

After my last blog post I have been finishing up automatically generated Level Of Detail (LOD) for the terrain system that has a configurable level count and scales based on other terrain settings. At this point I had completed all the tasks related to performance and optimization of all currently added features. The entire game engine was built in a way that made it very easy to test and debug core components, but as the engine is now in a more mature state I thought it was the right time to improve the architecture of the engine to allow for more dynamic development and automation. The goal was to make the engine a seperate library that is automatically included and set up using a project template. All components in the engine can be customized by inheriting classes and injecting project specific types on initialization. By doing this the development process feels like native programming using a graphics API, and all of these features are accessible through the game project when desired, but instead you are skipping the hassle of building every core and render feature by yourself. It’s a balanced combination of simplified component based development and lower layer programming.

Internal World Editor

Now with the new architecture all set I was able to build new systems on top of the engine. With game prototyping on the agenda I had to start building a good world editor to make maps/levels with. I considered multiple implementation options including making a seperate project that spit out map files. But this created a lot of programming overhead having a seperate tool and code base along side the engine itself, and it would make my plans concerning customizability and extensibility of the engine and game projects very hard to combine with the editor. Therefor I decided that implementing the editor inside the engine would be the best option. I didn’t have to start a new project, there was no need to update it along side the engine in the future and it automatically works together with the engine and game specific types. Only developers will need this world editor to create their game and it doesn’t have to be included in the final game release. To cut the editor out of the game automatically I assigned it to the debug build of the game exe by default, but it’s still configurable to enable it in the release build as well. The world editor currently supports moving, rotating, scaling, adding and deleting of objects and morphing of terrain shapes. There is also an undo and redo feature available that makes designing a little bit easier. More features will be added to the world editor while engine development continues.

So to sum things up, it’s now possible to create a new game project with just a few clicks. And by writing a few lines of code you can build custom objects, scripts or work with the underlying graphics API. You can inject game specific types into the engine and world editor, and design your worlds while you are playing the game. A final deployment of your game is done using a single build mode switch and automated asset file packing into a game folder.

Hey again! Progress on FPEngine is currently slowed down a bit because I’m in the process of rewriting core parts of the renderer for performance improvements. And since a culling system was added, a bug was fixed related to certain GPU’s and some optimizations are done, I thought it was time for a new performance test. At this point I’m simply testing the performance by checking the framerate with all graphical options enabled and maxed, using the same hardware for every test. I use this method to make sure that while I’m rewriting things the performance goes up and not down.

Using an Intel Core i7-4720HQ combined with an NVIDIA GeForce GTX 970M (3GB dedicated VRAM), the engine managed to reach 5.3 million visible polygons drawn on screen per frame before dropping below the 60 frames per second minimum. This is a massive improvement as the previous test resulted in 1.3 million. Right now the scene contains a point light that isn’t optimized yet. It draws every single car mesh that’s visible in its light camera’s into the cubemap for shadowing. So that means those 5.3 million polygons are all rendered for a second time in a depth shader. Performance will greatly improve once I get to implementing light range and selective lighting/shadows. Directional lighting (e.g. sunlight) is also coming up to light up the scene after I complete the core rendering tasks.

The next thing up the list is Level Of Detail (LOD). While currently having about 16k polygons per car mesh for the performance tests, it doesn’t mean that lower resolution meshes will improve the overall performance in a scene. I have to make sure that no more vertices are being processed than the ones required to make a scene look good. The engine will need LOD for both terrain and objects to filter out those unnecessary vertices in the distance, where you can’t see details in an object no matter how many you are drawing because it’s simply too small on the screen.

Today I decided to put up a page explaining some things about FPEngine. It is a 3D game engine that I have been working on for quite a while now.

It started out as playing around while still doing other work on the side, without any designing or planning ahead. But it kept growing, to the point where there was no other way around it anymore. FPEngine became the main project for Flying-Potato as the smaller ideas I had were all on hold while I worked on the engine.

For more details about FPEngine and some preview images, visit its page here: FPEngine.

I would love to hear your thoughts about this project and I’m open for collaborations. While the engine isn’t public yet and only used from inside Flying-Potato, there could be opportunities to make games with it before it gets released.