Game Engines Blog #5: 2LoC too many?

Alright so for my final blog I'm going to do something that I have no doubt that many of my classmates have already done: My personal gripes with 2LoC and what I would do to change it. Without further preamble, let's dive headlong into it!

Camera
First things first, setting up the camera is a massive chore to me. It's the kind of thing where you don't need to make a lot of cameras unless you're doing some special effects (i.e. reflection) so setting up a function to make it easier feels like it might me spending more time making a solution than you do on the actual problem. For an idea of why I might hate the camera, here's sample code to get a perspective camera working:

cameraEnt =
pref_gfx::Camera(m_entityMgr.get(), m_cpoolMgr.get())
.Near(1.0f)
.Far(1000.0f)
.VerticalFOV(math_t::Degree(60.0f))
.Position(math_t::Vec3f(0.0f, 5.0f, 5.0f))
.Create(m_win.GetDimensions());
{
//Set camera settings
math_t::AspectRatio ar(math_t::AspectRatio::width((tl_float)m_win.GetWidth()),
math_t::AspectRatio::height((tl_float)m_win.GetHeight()));
math_t::FOV fov(math_t::Degree(60.0f), ar, math_t::p_FOV::vertical());

math_proj::FrustumPersp::Params params(fov);
params.SetFar(1000.0f).SetNear(1.0f);

math_proj::FrustumPersp fr(params);
fr.BuildFrustum();

cameraEnt->GetComponent<gfx_cs::Camera>()->SetFrustum(fr);
}

Now, setting all the variables such as field of view, near and far during the camera construction only to have to re-declare this stuff when making a frustum feels REALLY redundant. I would think that setting this stuff up in the camera would automatically handle setting up the frustum during creation. Now you might say "Oh you have no indicator to set it as perspective, that's why!" Well, there is a function where you set perspective with a boolean value, but this doesn't seem to do anything. Overall it makes the whole process of making a camera, one of the most necessary entities in a game, feel like it has six more lines than it should while being simultaneously unintuitive as I don't think most users would think to create a frustum at this point in creation of the game.

Shader Limitations
Next up is the limitations on how you can use shaders with 2LoC. Creating materials and such is actually pretty simple and I do like it...But being unable to access the geometry shader (as well as the other lesser known ones) ends up hampering development. Case in point: Dealing with particles. Normally for a particle you could just send in a single vertex and then create a quad in the geometry shader allowing for things to be much more efficient in terms of calculations since you just have to apply physics calculations to the single vertex in the shader versus doing it 4 times (assuming you have vertex indexing in the engine!) on each corner of a quad. So this not only becomes a limitation of what one can do with shaders, it also becomes a limitation of how efficient you can make your processes and hurts development in the long-run!

General user unfriendliness
There's a few other problems I can go into such as the extensive namespaces which make dealing with things difficult (I have had many times where I couldn't copy a material over to another material because as it turns out material 1 is in namespace and material 2 is in a different one...Despite both being materials) as well as things that the engine could benefit from but doesn't have for school reasons (i.e. Scripting and Particles) but above all else is just how obnoxious the engine can be to use. There are a lot of tricks that you need to sort of work out for yourself in order to get some things to work and it might be easier if we had some rudimentary documentation to go by (i.e. A list of what the different functions do) but without this it makes it very challenging to work out how to do what should be very simple things. For example, when I create an entity during runtime its mesh and material won't appear unless I call the appropriate systems and say "Initialize(ent)". I would not have guessed that I need to do this until a friend pointed it out to me.

Overall, the engine seems to suffer from a serious problem in that it's usable once you have become used to (which isn't really praise since it can apply to ANYTHING) the engine but it's very unfriendly to new users and would benefit from a bit of documentation to go with the samples provided. Even something as simple as "Here is a list of basic functions you should know but aren't immediately found and what they do:" Just to provide users with the ability to easily reference something like they would with Unity's documentation. In the end, the engine has a long way to go before I'd say it would work well as an engine for general use.

That's it! Sorry if I seem a little bit harsh but this engine has bitten me too many times to count and has left me a bit miffed. I hope you enjoyed the read, cheers!