How to approach Game Engine Development

A couple of weeks ago I was assembling a new piece of furniture for my apartment. As I was putting all the pieces together, I made sure not to tighten the screws until all the parts were in place. Such workflow reminded me of the process I took to develop the Untold Engine.

If you have been reading this blog for a while, you would know that when I started developing the game engine, I knew very little about Computer Graphics. Moreover, my C++ programming skills were weak.

Keeping into account my technical weaknesses and my desire to learn, I approached the engine's development the same way you would assemble a new piece of furniture. That is, I made sure not to tighten the screws until the end.

What do I mean with this phrase? I didn't focus on Perfection. I didn't write each piece of code to the highest standard possible. Instead, I focused on writing code that was Good Enough.

For example, the Collision Detection System is the most complex component you will have to implement. This system requires you to implement several algorithms such as the GJK, BVH, Sutherland-Hodgman, etc. My initial implementation of the GJK was very crude. However, instead of making it Perfect, I decided to move on and implement the Sutherland-Hodgman algorithm. Again, my implementation was crude, but it was Good Enough. Finally, I implemented the BVH algorithm.

I had all the major components working. Their implementations were crude, but they were Good Enough to detect a collision. I had in my hands a crude Collision Detection System, but I had learned a ton in the process. I learned how all these algorithms worked together to detect a collision.

After I understood how these algorithms worked together, I went back and re-read several chapters on Collision Detection and several articles on the algorithms mentioned above. Armed with new knowledge and experience, I was able to improve the Collision Detection System. I think I was able to do so because I saw the system from a holistic point of view. I understood the system weaknesses and strengths. I was able to see the whole picture.

Developing a Game Engine is tough. There is a lot to learn, and you will make tons of mistakes. In the beginning, avoid Perfection. Once you have a good grasp of what you are doing, go back and improve your code. Just like assembling a piece of furniture, do not tighten the screws until the end.

Languages required to develop a game engine

A while ago I responded to a question on Quora regarding which languages are required to develop a game engine. In this post, I want to expand on my answer.

The one thing to keep in mind while developing a game engine is EFFICIENCY. And it was the closeness of C++ to the bare metal that finalized my decision to use it as the primary language of Untold Engine. The other motive was my desires to learn C++ at a deeper level.

Collision Detection is the most expensive operation in a game engine. A proper Collision Detection System must detect a collision, compute the where the collision occurred between two convex entities and compute the collision responses. Furthermore, to efficiently detect collision among several entities, a game engine should parse the scene and divided the detection between two stages: Broad and Narrow Phase stages.

Such operations require the implementations of a Boundary Volume Hierarchy algorithm and a GJK algorithm. These are expensive operations, and they must be computed within a fraction of a game-tick.

Therefore, whatever primary language you decide to use in your engine, make sure that it is a fast and efficient language. The last thing you want is for your game engine to waste valuable time in the collision detection due to the inefficiency of the language.

Aside from the game engine, you must also develop an application that acts as a bridge between your engine and 3D modeling software, such as Blender 3D. The primary purpose of this application is to export rendering data of a 3D model from Blender and make it accessible for the engine to use. To develop such an application, you need to learn Python-Blender scripting.

During the development of the Untold Engine, I had to develop this application, which I call Digital Asset Exporter (DAE). The DAE not only exports rendering information but also 3D animation data which the engine can use.

Depending on the 3D Modeling tool which you decide to use, you may have to learn a different second language such as javascript. For example, if you choose to use Cheetah3D, you will need to develop the DAE using Javascript.

Well, I hope this helps.

Managing your schedule to develop a game engine

A while back I received an email from a reader asking me how did I manage my schedule to develop a game engine. I feel that his question is a common question among most of us.

So how did I do it?

The development of my game engine can be divided into two periods: "Prior the development of the Basic Framework' and "After the development of the Basic Framework" of the engine. By "Basic Framework," I'm referring to a game engine that has the four primary components implemented. Such as Math Engine, Rendering Engine, Physics Engine, and Collision Detection System.

Time Management Prior the Basic Framework

When I started the development of the engine, not a single free hour was wasted. I had only one goal in mind, and nobody or nothing was going to stop me. My schedule was very extreme:

• Wake up early in the morning, usually at 5 am and work until 7:00 am or so.
• Head to work
• I tried to eat lunch at my cubicle as I worked, and used my lunch hour to go to Starbucks (or Coffee Bean) and worked on the engine
• Go back to work
• At around 6 pm, I would head to the Gym or play soccer for about an hour and come back home
• Work on the engine from 7 pm to 1 am or so
• Repeat

During the weekends, I would work on the engine for about eight hours each day.

Looking back, I think that I was taking my desires to develop a game engine a bit to the extreme. I should have relaxed a bit more. However, back then I felt that it was the cost of doing what I wanted to do.

Time Management After the Basic Framework

There is something about Game Engine Development that you should know. Once you implement the Basic Framework of the engine, everything gets easier. Developing the Basic Framework is the hardest part of a game engine. Trust me.

My schedule during this period is more relaxed. I no longer put an inordinate number of hours on the engine. I work on the game engine for about 2-3 hours each weekday. During the weekends, I may work 5-6 hours total.

Looking back, I realize that I was able to do all this because I have no other obligations aside from my full-time job (I work as an engineer). I am not married, I have no kids, and I'm out of college. So, I have a lot of free time. I understand that many of you may not be in my same situation.

So, back to the original question: "How can you manage your time to develop a game engine?"

I can't tell you how to manage your schedule. My situation is different than yours. However, the one tip I can share with you to make the best use of your time is this:

Do not code right away. I have realized that after I learned a new concept, and try to implement it in code right away, I would end up wasting a lot of time fixing bugs. Instead, try to internalize the newly learned concept. Visualize the implementation as you are heading to work or school, while watching Netflix, while eating, etc. Think about it as long as is necessary. Think about how it will affect the architecture as a whole. Try to foresee what bugs will arise and how other components in the engine will be affected. Once you have a clear idea of how to implement the new feature, then open up your laptop and start coding.

You will realize that the time spent visualizing the implementation leads to less time being wasted fixing bugs.

So, do not code right away, instead try to visualize it first.

Hope this tip helps.

Tips to make Game Engine Development a joy

Developing a game engine is an insanely complex task. Not only will you spend thousands of hours trying to get the first version of your engine to work, but it will also test your persistence. Thus, developing a game engine is more of a psychological feat than a technical one.

Before you embark on this journey, I have some tips for you.

Play with other engines

Before developing your engine, spend some time developing a couple of games and using a couple of game engines. Use this experience to gather features that you like and dislike from each engine. For example, you may like how friendly an engine's API is versus the other.

Keep this in mind: Developing an engine does not only mean implementing amazing graphical features. It also means developing a user-friendly API which developers love.

View it as your favorite hobby

Again, developing a game engine is insanely difficult. I can't even express how difficult it is for one person to develop one. And not everyone has the stomach to work for thousands of hours before seeing their creation come to life.

So, if you want to see this through, you need to view engine development as a hobby. Don't rush, just sit back, open your laptop and enjoy. It may take you one year, two years, five years, who cares. Just enjoy and fall in love with your engine.

Is OK if some features are half baked

Not every feature in your engine needs to work correctly. Not in the beginning anyway. If rendering Shadows work 70% of the time but fail within some conditions; make a note of it, take a break and move on.

Don't kill yourself over it. Remember, this is your hobby, your favorite pastime. You have no deadlines, no nothing. All you need to do is promise yourself that after a while you will come back to fix the issue.

It is important to consider that when you start the journey to develop your engine, you will not know everything about computer graphics. And you will not know what you don't know.

Features may not work as you hoped for initially, but this is OK. It is a process of failing and learning. Let me give you a recent example.

Last week I ported the engine from OpenGL to Metal. As I was doing the porting, I noticed that some implementations I had done a couple of years ago were incorrect. At the time, I thought that they were correct. But the experience that I've gained over the years spot these mistakes right away.

Don't let perfection immobilize you. If a feature is not working 100% as you intended, make a note of it, take a break and make a promise that you will come back to fix it in the near future.

Thanks for reading

Should you start a technical blog?

I started this blog on Dec 2014. I've been writing for about two years (and some months) and have published about 190 articles. I think I have enough experience to comment if you should or shouldn't start a technical blog.

First, let me start off with the harsh aspects of blogging.

Writing Consistently

The hardest part of blogging is making writing a habit. I love writing, but I must confess that writing regularly has been quite a challenge. There are times when an influx of writing energy flows through me that I end up writing a post a day. Other times, I go weeks or months without writing a single post. I used to fight this writing drought by forcing myself to write, but I realized that writing is like music. When it comes, it comes; there is no point in pushing it.

No rewards for a long time

This past January I got about 3.5K visits. That is the highest number of visits I've ever gotten in a month. However, during the first year, my average number of visitors was less than 20 a day.

Be prepared to write and have no one read your articles. This fact brings me to an important point; your purpose should be to HELP readers, not be concerned about your blog stats.

If helping your readers, even if it is only one, brings you satisfaction, then blogging is for you. Else, do yourself a favor and find another hobby.

Now, let me share the positive of having a blog.

Your writing will improve

Writing is a skill. You need to practice it to improve it. Blogging is the perfect stage to practice this skill. I have noticed a huge improvement in my writing. If you go back to my articles written around 2015 and compare them to recent articles, you will see improvements; not only in clarity but also grammatically.

You get to help people

Helping others is the one reason that makes blogging worthwhile. I feel an enormous sense of satisfaction every time I get a message from a reader thanking me for a post or asking for advice. This type of satisfaction is hundred times more rewarding than seeing your blog stats improve. A "Thank-You" message from readers like you, makes all the trouble of writing an article worth it.

You will become an expert

It is interesting how cracks in your understanding of a topic emerge once you start teaching others. As a matter of fact, It was writing that improved my understanding of game engine development and allowed me to complete my project.

I modified the engine's architecture several times after writing an article. Writing and teaching solidified my understanding and gave me ideas how to improve the engine. Teaching, not coding, enhanced my computer graphics knowledge.

So, should you start a technical blog?

If your goal is to express yourself through writing and you have an honest desire to help others, then blogging will be rewarding. However, if your goal is to make money like some bloggers have been able to, then be aware that the money will not come that easily and it may take a while.