• entries
8
0
• views
8777

Journal and progress of my Engine, which is currently unnamed.

## Plans and Progress #1

Welcome to the first part of what hopefully will be a look on a week-to-week overview of my development life!
Here for you to see my mistakes, so you don't have to make the same ;) (unless you want to, have fun!)

Plans!
The next week is the week where I finish off a simple "engine" of sorts, so I can start doing some rapid game devs, making simple little games for experience, and fun. If I actually sat down, focused, and did it, I'd be done it in about a day, or two... so yeah...I need a week.
Next month, and the months following, I'll try to make a game a month, using this engine.

What's my focus in all this? Learning. Exploring. Fun.
Now, why did I make my own engine? Why not grab Unity, Unreal, ? Learning. Exploring. Fun! That and a bit of pride too.
Do I suggest you to make your own engine? I would suggest against it, unless you're a pretty good programmer, and want the headache/want to learn. If you're new, but want to learn, find an open source engine, rip it apart, look at the code, try to understand why they did what they did.

Progress!
*looks at code, twiddle thumbs*
Well...I coded, not much mind you, it's enough to get stuff on screen and working; I'm just re-immersing myself to OpenGL's API again; But everything not OpenGL related is pretty much programmed in right now. So that's nice.

Later on, I'll be showing screenshot progresses as well, but...a screenshot of code/empty screen isn't that interesting :P

Any suggestions, comments or what nots, are welcomed!

Have fun and happy coding!

## Progress Restart Again...

Typically I don't do this on a tuesday, well, if you actually looked back, typically I don't do this at all anymore...

Most of my attention before was focused on making a BIG game, something while, I feel I could still do, I already know that my current skills and attention span, (mainly attention span) won't ALLOW me to do. So, after sitting in a low for a bit I decided that hey, there IS something I can still do!

What have I done, in the past, which illustrates what my current attention span will allow? At most, 2 months projects before I burn out, forget my code, come back a month later to look at it and say to myself "What the **** was I thinking?!". So that indicates I should work on way smaller scope games than I was previously aiming for.

As always, I'll be documenting everything I can, so you guys can see the fun, mistakes, errors and joy that comes from this indie dev!

I'll be posting here every week for people to follow me here, and posting on twitter ([twitter]nightlonegamer[/twitter]) almost every day or so for those who want to follow me step by step and interact with me more directly.

Have Fun, Keep Deving, Stay Alive!

## NLE: Unnamed Engine. Entry #6: A week has gone by? really?

Well...I'll be honest...
Not much has been done...
programming wise that is.

Been mostly playing around with ideas trying to figure out a few misc things, all of which I cannot say cause, well, don't wanna promise something unless it's official!
I did change up the lighting a bit though, I now have the normals transform properly when something is rotated and/or scaled, and adjusted the light to have a strength value so it'll spread x distance before dying off completely, this allows for some more realistic lighting.

I am playing with some AI ideas though, and I've created a little character in which I'll need to 3D model and place him in later :)
Things are happening!!
Slowly...
I'll be continuing my AI research though, so don't expect too much done next week either.

I did promise I'd do this every week so I will!!

Have fun!

## NLE: Unnamed Engine. Entry #5: I see the Light!

Well, we have a bunch of things to talk about this week! So lets shed some light on the subjects and get going!

First of all, I've replaced the old [font='courier new']ShaderProgram[/font] class with a system/component for entities, allowing entities to hold their own shaders. I've, of course, named this the [font='courier new']ShaderSys[/font], and it's primary job as of now is to check which is the active shader program, switch to a different shader program if need be, and to compile shader files into a shader program. It's also now extendable, allowing for easy upgrades

The system before only allowed one shader program for the entire app, and, as we all know, that's usually not a good idea. While it was possible to switch between two [font='courier new']ShaderProgram[/font] objects, doing so was asking for a bit of trouble (I would explain, but that's another article I'm unwilling to write).

Because of this, the [font='courier new']RenderSys[/font] had to be updated to use the [font='courier new']ShaderSys[/font]'s new functionality, This was pretty easy, but I may end up changing it. Currently what's happening is this:
- for each mesh attached to render:
+-- check if it's using that shader, if it is, render it.

While that's all fine and dandy, it COULD be sped up, by a few ways, BUT as the wise people say,
"Premature optimization is the root of all evil."
Also, another one of my fave quotes:
"Rules of optimization:
1) Don't do it.
2) Experts only: Don't do it, yet."

# The Light System.

Yes, I've finally done it. I finally decided it's time to see the light... (Okay, last Light pun, promise)
The [font='courier new']LightSys[/font] was the main reason for my to make the [font='courier new']ShaderSys[/font] and now well... things are a bit more beautiful. As a picture is worth a thousand words, here's two thousand words of before/after:

[size=2]Btw, the white ball is above the sky-blue platform.

It's pretty standard to use,
[font='courier new']AttachLamp(entity);[/font]
[font='courier new']Loop:
-UpdateLight();
-Render();
Delete everything;
Quit.[/font]

Right now, it only supports a single light, so doing multiple [font='courier new']AttachLamp()[/font]'s will do nothing, the first light will be the one chosen. As of currently it also only supports a point light as well. The [font='courier new']LightSys[/font] will be updated when I need the other types of lights.

# Bug Season

Yay for mosquitoes and blackflies! They're about as annoying, if not more so, than computer bugs! And I got two bug reports to report, thankfully they're fixed already
I took a while to find this one out: Unnamed Engine has the ability to still be able to play a game, even if there are assets it can't find. It will replace missing assets with "default" ugly as hell ones. Thats good and dandy right? That is, if it worked!
Default texture works...Default shaders worked...Default model....was missing...took me a while to hunt down what went wrong, and I finally got at it, which showed a new bug (yes, it showed a new one, it didn't create it)! Yay!! T.T

[font='courier new']ComponentManager[/font] ([font='courier new']CM[/font]) is the thing that connects Components with Entities...All good right? Well, apparently it had the ability to also "manage" [font='courier new']NULL[/font] components...What does this lead to?
Game asks the [font='courier new']MeshSys[/font] for a Model, Model not found, so a model was created. Awesome.
Game asks for another Model, that model wasn't found, so a model was...not created, because we already had our default model, saving memory!! Yay! Oh wait, so it just passed [font='courier new']NULL[/font] to the [font='courier new']CM[/font]? <--bug

[font='courier new']RenderSys[/font] then asks the [font='courier new']CM[/font] for model #2, you know, the [font='courier new']NULL[/font] one...
[font='courier new']CM[/font] happily gives it a [font='courier new']NULL[/font] model... <---BUG
[font='courier new']RenderSys[/font], assuming it's a valid model, tries to render it...SEGFAULT <-- Another Bug!

So now, [font='courier new']CM[/font] now refuses [font='courier new']NULL[/font] components, and therefore can't give out [font='courier new']NULL[/font] components (2 weeks later, it gives out another [font='courier new']NULL[/font], just you wait and see!). And now the [font='courier new']RenderSys[/font] checks to see if it's been given a [font='courier new']NULL[/font] component, and then just ignores it.

# Last but certainly not least.

While I was doing the [font='courier new']ShaderSys[/font], I decided to rename my haphazard shader names to something... a bit more easier. Any variable that will be inputed to the Vertex Shader is now prefixed with vs_, and Fragment Shader is now fs_.

Simple little things like that, really makes it a joy to program, why?
cause you're not trying to remember if the variable is [font='courier new']IhEaRtCaKe[/font] or if it's [font='courier new']iHeArTcAkE[/font];
And...If anyone had a variable called that, and I saw it, they would suffer... A Lot.

Lesson here: Make all your variables make sense, readable, and in some standardized format that's everywhere in the project. Having one cpp file that uses camelCase when the rest use CamelCase can really make life hell for a few seconds!

Anyhow, that's it, that's all, for this week

Have fun, don't stop doing what you love

## NLE: Unnamed Engine. Entry #4: NEW OFFICE!

This week has been busy, I've fixed a little problem with my shader loading functions (rather, I forgot to code the darn functions before which messed me up until now) and been researching a ton. I've also coded some limits into the FPS Controller System. Lastly I got a new office.

# So, Code Stuffs first!!

You can learn about it at http://www.opengl-tutorial.org/

The interesting bit was limiting the rotations, as I'm using quaternions instead of Euler Angles/Axis-Aligned. So here's the summary:
First, I need to know where I'm looking, for that I did this (Camera Rotation = c, Congruent of c = c', and unit vector with a +Z direction = z) :
[font='courier new']d = c * z * c' ;[/font]
This gives me the direction I'm looking, as a vector (actually it's still a quaternion*). Now I use the Dot Product of d (direction) and of the +- Y Axis to see how close I am to going vertical, and therefore doing some bad things (like reversing the mouse movement). If it's really close ( d o y > 0.95) then don't allow it to continue tilting upwards.

# Now, the research stuffs

For the first planned game for Unnamed Engine (Might become the official name xD) will be a very simple one, but it may need some complex AI to be able to do right. So currently I'm doing some AI research in my spare time, thinking about things and how to make an AI that feels "real" enough to the player.

# Finally. The Office.

A picture is worth a thousand words so:
https://pbs.twimg.com/media/CGEnk--U0AAmMR9.jpg:large

This is a lot better than a TV Dinner table I was using for my laptop!

Thats it, that's all. Until Next week!

## NLE: Unnamed Engine. Entry #3: Better late than never

I took this week studying a few things. Unfortunately that means that not much has been done; in fact I could paste what I've done here, if it wasn't in 10 different files!
So, what have I been studying? Well, a few things really, each with their own link of goodies!
First off, I found this wonderful "walkthrough" of the graphics pipeline, here. Pretty good if you want a "low-level" of understanding of the graphics pipeline. Take note that this isn't very low-level, not as low-level as hardware, which is most of what this guy is talking about. I'm still not finished it yet, but will sooner or later

Next, I've been looking at some OpenGL stuffs, something a little more ahead of myself, do I really need to link you to the OpenGL wiki? I'm sticking with OpenGL 3.2 for this engine, as my mac only supports that, also, 3.2 is all I need for now. I'm just learning a few new tricks here and there, nothing too important to talk about.

And finally I've also been looking up some other physics-y math stuff in a wonderful book, unfortunately I can't link the book to you, so here's the name: Real Time Collision Detection, David H. Eberly. A quick google search should lead you to it. There's probably countless pdf's of it, but I won't be endorsing them

Also, for future programmers, new programmers, and for a reminder to all.
When you make a class/template/function/etc in a programming language, if at all possible, FINISH IT. Reasons:
1) When you go back to your code, and you expect X to work X will work!
2) if someone maintains your code, s/he won't want to murder you for unfinished functionality. and
3) It's a good habit to get into. It'll also save lives...maybe...or at least a few headaches!

Tomorrow I have a busy day fixing stuff that should've been fixed months ago...

If (programming) things go well a few weeks from now, screenshots will be coming! Hopefully

Until Next time!

# Welcome back! or if you're new to my new blog, please read "The Start...Kind of..." first!

Now, I'm going to try my best to make Friday, Blog Day, So yay!
[size=2]or at least do this once a week...

Let's cut to the chase and this is what I did all week, programming wise:
[font='courier new']FPSControllerSystem[/font]
Long story short this is what makes controlling something, usually the camera, in an FPS like feel; WASD movement, mouse to look around, Space to jump, Shift+W to run, and C to crouch/crawl. In flying mode (the only mode currently supported) jump and crouch = fly up/down.

This will be the first system in which is purely optional for users of the engine; where as, Rendering is usually needed, and with Rendering, you'll need positions, meshes, and a camera; (well, unless you want to render nothing at 0,0,0) Oh and don't forget Textures! But that is kinda optional, but due to the fact it'll be used a lot, it's not as "optional" as I could've made it. Currently, one cannot have "no" texture on. Will probably "fix" this later.

I also remade the event system...actually the event "system" was ditched, and replaced with a class that is separate from the "system" pattern I'm using. The reason for this is that, well, entities don't really "accept" keys or mouse inputs; they could be made to, but I found it was 10x easier to ditch the "system" pattern this one time.

Another change today was the fact that Systems now can use other systems, right now it's a bit ugly but it's doing it's job. Going to do something to change it later down the road.

Also, each system now has a [font='courier new']Couple()[/font] function which can Couple the needed [font='courier new']ComponentManager<>[/font]s and systems. It may be smart to make the [font='courier new']ComponentManager<>[/font]s to be gobal, or collected in a general class/struct that can just be passed to the systems; and same with the systems, but I'm gonna try to avoid that if possible, as (or so I'm told) globals = bad; and that would probably be an ugly hack which will allow too much access.

To finish this blog entry, I gotta say that the engine is slowly morphing each day and soon(TM) enough there will be a game running with it.

What game am I planning? Now that's a secret ;)

Next Week:
no clue, Might do lights though...assuming I'm not stuck fixing something stupid!

PS: Any idea's for the name of the engine?

# Welcome to my n[sup]th[/sup] attempt at making a steady blog for myself and my projects!

So, to help others, and myself, I'm gonna write some snippets of stuff here, and hope the ideas, methods and over all the posts I make will help out someone

First of all, an introduction to my Unnamed engine.

The engine is built along a certain 'pattern' (as I'll call it), this pattern has 3 simple parts to it, "Entities", "Components", and "Systems".
[size=2]Now, I can see people yelling, "That's an ECS!" ... I can also see Hodgeman raging at them ... If you're curious about my last statement, don't be, I'd love to explain it but I have forgotten what Hodgeman said exactly, so I really don't want to "quote" him and get it all wrong, and have him rage at me

Entities in this pattern is just a number, a handle, it basically there to help mapping things; though, as simple as it is, it is a very important job.
Components in this pattern is data for the entities, each entity is linked to a number of components using a [font='courier new']ComponentManager[/font] class.
Next up is the Systems, which are classes that actually contain functional code for the entities and components. All Systems have an "Attach" and "Detach" function, and most have an "Update" function;

A perfect example of how this could be used is the RenderSystem://usually in some sort of "init()" or "load()" functionrenderSystem.Attach(myEntity);//in the game looprenderSystem.Render(); //aka Update.//in a function called kill() or the likerenderSystem.Detach(enemy);
This pattern is also easy to change, or replace, as long as any future "renderSystem" has "Attach, Render, Detach" I can easily just replace one line in my project, which would be the declaration of the [font='courier new']renderSystem [/font]variable.

The goal of this pattern I'm using is that everything can be swapped out, or even completely ignored without hindering the rest of the program, and that adding new things should be very easy.

To summerize my engine, here's a list of the systems and components so far.
Components:
[font='courier new']Camera[/font]
[font='courier new']Transform[/font]
[font='courier new']Mesh_GL
Texture_GL[/font]
Systems:
[font='courier new']Camera[/font]
[font='courier new']Movement
Render[/font]
[font='courier new']Mesh[/font]
[font='courier new']Texture[/font]

As you can see, the Components and Systems are duplicated, the reason for this is that the Components only hold the per-entity data, and the Systems "attach" components to the entities, and also work on the components that entities have.
Another way to think about this is that the Systems are the functional properties an entity has. As, an entity attached to Render, is able to be rendered, that is, as long as it has a Transformation and a Mesh, and possibly a texture.

The engine so far is very "young" but in it's current state, adding to in, updating it, and changing it isn't very hard, all parts of the pattern are separate, and because of this, they don't mess with eachother.

Now, looking at this, you may be wondering:
Why not just have a class, that has parents of which the properties I have listed? like, class Camera{public: //stuff that's in CameraSystemprivate: //stuff that's in CameraComponent}class Transform{ //movement and transform stuffs here}class PlayerCam : public Camera, public Transform{ //player stuffs here}
Well, I could, but then, as soon as I changed something in Camera, I must ensure that all my code has that change. Also, if someone else is using this engine, they must know about this change; but, thats not the biggest issue, that's just a minor annoyance. (To me, that is)
The bigger issue is:
What if I want to dynamically add a feature to an entity? It's of class "Flying" and in the game, I've told it that it's now explosive? I can't do that with classes, I'd need to have a list of all "types" it could be, and see if it's that type. That carries the problem that some objects may just be static, and always static, and the player may not change the type at all.

This dynamic, on the fly, ability is useful for other things as well, like allowing users to mod the program using files. We can't tell what the user will make an object, and if we can't tell, then we can't make a class for it. We could limit the user, but that isn't nice now is it?
This is just a small example of why this is useful.

Anyhow, in the next posts, hopefully next week, will be an update on the engine, showing (maybe) the new features, sharing what has changed, and why I changed it.

If you want to know more about "Entity Component Systems", here's a good link: http://gameprogrammingpatterns.com/component.html

Until Next time!