What is KipBGE?

KipBGE (short for KiPhemyt’s Block Game Engine) is a game engine I am working on during my free time. It all started September 2010, I wanted to learn DirectX (and improve my C++ skills) and thought that making something similar to Minecraft would be an interesting technical challenge (yea… I was naive like that and thought that it should not be very hard). After a year messing around there finally is something to show!

Wait a minute… is that another “Minecraft clone”?

Yes and No, well not really. Yes it uses similar terrain system, but you should know that Minecraft was not first game to use it, Infiniminer was (it was before MC that’s for sure)! Also there are no gameplay elements yet, so comparing it to any game at all is hard, well that’s why it is “game engine” after all.

Design Philosophy

Since I wanted to learn DirectX and improve my C++ Programming skills I decided to only essential libraries and SDKs for my project, that means no ‘wrappers’, no XNA, or anything similar. This slows down the development, however in the process I can learn A LOT about how and why stuff works (well it does not work most of the time… but that’s just details… and be details I mean hours of making it work), also since most of the code is my own, I know what each line of code does, and fixing problems is easier when I do not have to deal with someone else’s code. Currently I am using DirectX 10 SDK, DirectInput and AssImp (I don’t have any models to import yet, but it works for static meshes).

Current “Features”

Let’s see what I have currently implemented, for some people it might not look like a “feature” at all, but when making a game engine from scratch all these things need to be created as well (assuming you are not using any libraries) and they cause their own problems etc.

Graphics Related

  • Camera class with pitch angle locked -90 to 90 degrees (assuming 0 is when looking straight forwards) with no Gimbal lock. Camera also supports frustum culling on standard shapes: Axis-Aligned bounding box, sphere, point.


  • Shader class for loading shaders with different variables. It allows me to set which variables shader is going to have when loading it so I do not have to write different class for every single .fx file I want to use. For example if I decide that one of the shaders now need a inverse view matrix, I can set a flag when loading that shader, and when I pass a view matrix into shader, it will calculate inverse matrix for me. (Fun fact I used word “shader’ 7 times in this bullet-point).


  • Texture manager class, that makes sure no texture is loaded twice, also makes sure all of them are unloaded when application quits. Also it manages all the texture pointers so other objects just store the name of the texture. This will come in handy when creating UI elements if multiples have to share same loading bar texture for example.


  • DirectX 10 Texture Arrays allow each block to use a texture up to what ever your video card supports (I believe DirectX 10 cards are required to support minimum resolution of  8192×8192) and up to whatever many texture you can fit into VRAM… However anything above 512×512 is an overkill unless someone decides to make cubes bigger, but we want smaller for more detail… so yeah… I am using 256×256 at the moment and it looks pretty well (in my tests 512x looked seamless and 256x is a little bit blurred but if you are more than 0.5meter away you probably wont see a difference… unless you screen resolution is ginormous). (Original idea how to implement that by Slaihne12)


  • Light system supports up to 4 “environment” (Static light sources that shine from a block as a source) and all colors in between (when there are multiple light sources nearby, lights cannot emit two lights at different strengths, for example red 1.0 and blue 0.5 wont be ‘deep pink’ all the way, but will lose all the blue component at half the way of lit area).


  • Simple system for GUI, nothing to special just clickable buttons, and some colored rectangles… Interfaces are not hard to program, but they are annoying in a sense that making a menu gets boring and repetitive very fast.
General Stuff
  • How do we allows player to click something in the game? Well we use Picking… and since most of the scene is not DirectX mesh which has Picking functions build in…. I implemented ray class and ray-triangle intersection function myself.
  • Octree structure for faster Picking, Rendering, Physics and other functions.
  • Support for “Infinite” world you can go as far as you want in any direction, and after hundreds of years you will circle around the world. Physics, Light and other systems will work just fine, however current terrain generation is way too simple to generate correct terrain after some point, but that will be fixed at some point. Only downside is that multiplayer might be harder to implement… so lets say single player only… for now.
  • Physics system: works well with player-terrain collisions, also has support for ‘convex mesh-convex mesh-terrain’ collisions… in theory… I drastically changed the code three times and did not test it after the last one… so it probably (99% chance) does not work, but I will reimplement it at some time since now I know a lot better way to do it.
There are some other stuff that makes everything work together, but it is not that interesting…

Leave a Reply

Your email address will not be published. Required fields are marked *