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

Porting the game engine from OpenGL to Metal

If you are not aware of, Apple came out with its own graphics library; similar to OpenGL, a couple of years ago. The name of this graphics library is Metal.

When Metal came out, I had barely finished the first stage of my game engine. Back then, I thought that it would be a good idea to port the engine to Metal. However, I resisted in doing so, until Metal became stable.

Well, on the weekend of July 4th, 2017, I happened to play around with some Metal demo apps, and I was impressed at Metal's power. It was then that I decided to use my four-day weekend learning and porting the engine from OpenGL to Metal.

And so I did.

I spent Saturday morning to Tuesday night learning Metal in depth. I didn't even go out at all during those four days. I was focused and excited to learn about Metal.

On Tuesday night, I laid out a plan on how to port the engine from OpenGL to Metal. All in all, the porting took about two weeks. There are some minor bugs to fix, but all in all, I'm pleased with the results. Here is a screenshot of the engine using Metal.

Engine using Metal

So what did I learn?

Most of what I know about Metal, you can find it here. I wrote these articles a while ago,; I used them as a reference during my review and the porting. But here are the main things that you should know about Metal:

• Metal is not as convoluted as OpenGL. Metal is clean and has the concept of Objects. You can think of it as an Object-Oriented language, but for graphics. It is amazing to work with. Seriously.
• Metal is less forgiving than OpenGL. During the porting, I noticed many incorrect Computer Graphics implementation done in the engine. At first, I thought that the issue was with Metal but then realized that I had made several mistakes using OpenGL. OpenGL did not make a big deal about it, but Metal did mind and kept spitting out error messages. For example, I had incorrectly implemented certain aspects of Normal Mapping, Shadows, and Vertex-Skinning.
• The Perspective and Orthogonal projection matrices you use in OpenGL based games will not work on Metal. You need to compute a different projection matrix for Metal. The reason is that Metal uses a different coordinate system than OpenGL. I will write more about this issue later. However, if you need an example of these matrices, send me a message, and I'll provide you with one.

It is amazingly simple to work with Metal. However, since there are not plenty of tutorials out there, it may be hard for a newbie to get Metal working.

If you have experience working with OpenGL and have a good grasp of computer graphics, Metal will be a piece of cake to learn. I can guarantee that you will love it. However, if you are a newbie, keep in mind, that it may take a while for you to grasp Computer Graphics concepts and Metal at the same time. Hopefully, these articles can help you out.

Thanks for reading.

Implementing a Pathfinder algorithm- Soccer Game v0.0.6

In this version of the game, I implemented a Pathfinder algorithm. As the video below shows, the AI system computes a path towards the goal. Notice how the white jersey player drives the ball towards the goal.

Implementing a Pathfinder algorithm requires knowledge about Graph Theory and the Dijkstra's algorithm. I've heard about these topics, but I wasn't well versed on them. So I decided to spend my weekend reading about them. I did learn a lot. However, as I was about to implement the algorithm, I realized that the Dijkstra's algorithm might not be suitable for soccer.

Let me explain.

In Graph Theory, a graph is composed of nodes and edges, as shown in the figure below:

A node can represent a location. An edge represents a connection. For example, you can go from your Home to the School by taking the path towards the Park. Or by taking the path towards your friend's house and CoffeeHouse.

By scanning the image, you can see that the shortest path from your home to school is towards the park (only takes two connections). However, this route may not be the fastest.

If each edge is given a weight; in this case representing traffic, then the fastest path is the one towards your friend's house. The Dijkstra's algorithm is used for these instances. It analyzes a graph and determines the fastest path between two endpoints.

I figured that I could use the Dijkstra's algorithm in the game. My idea was to compute the path a dribbling player can pursue to reach the goal.

However, the Dijkstra's algorithm works well for static nodes. It does not operate well in a dynamic environment such as in soccer. For example, a path computed at time t=0s will be invalid at time t=1s.

So, instead of using Dijkstra's algorithm, I decided to implement a "Look and Go" algorithm. The algorithm works as follows:

Once a player obtains possession of the ball, the algorithm divides the player's surrounding area into 36 positions. The algorithm then scans each location. If an opposing player is close to the location, the algorithm discards the position.

The algorithm then analyzes the location that would bring the player closer to the goal. The AI system uses this information to move the player towards that direction.

Does this algorithm work? It works quite well as shown in the image below.

As you can see, unlike the Dijkstra's Algorithm, which computes a complete set of paths, the "Look and Go" algorithm analyzes one path at a time and is more suitable for dynamic environments.

Cleaning up the AI Architecture- Soccer Game v0.0.5

The video below shows the latest implementations to the soccer game. In a nutshell, I cleaned up the AI architecture and implemented a Player Indicator.

Implemented modularity to the AI system

This month I focused on cleaning up the AI game architecture. As it turned out I was violating an OOP principle which states that:

A class should have only one responsibility.

In my case, one of the classes was not only responsible for assigning roles to each player, such as the attacker, defender and supporter role. It was also responsible for executing AI algorithms.

To remedy this, I created several classes responsible for AI operations. Specifically, I created an AI class responsible for Defending. And another class responsible for Attacking AI operations.

However, I went further and created an interface for these classes. Doing so provides modularity and flexibility whenever I need to change an AI strategy.

I also implemented methods in the AI to steal the ball from the attacking player. However, it does not know what to do once it gets possession of the ball, yet. I plan to fix this soon.

Added a Player Indicator

In the previous version of the game, it was somewhat hard to follow which player had possession of the ball. To remedy this, I added an indicator which shows who is the dribbling player and what is its heading. The indicator also points out the current defending player.

Improving the Soccer Kits

Finally, I decided to hire a game artist. I was not happy with the soccer kit texture; which was painted by me. He is currently working on the soccer kits, and I like what he has done as of now. Hopefully, by the next version update, I can show you a small video of the game with more realistic soccer kits.

Thanks for reading.

Become a documentarian of your work

I enjoy reading rags to riches stories. They are powerful, inspirational and they resonate with our emotions. Humble beginnings connect us. They are a reminder that no matter who you are, or how broke you are, you do have a chance to succeed.

Game Engine Beginnings. Circa 2013: Implementing the rendering engine.

Now and then, I search on Wikipedia the stories of successful companies. I look for any photos that were taken before they made it big. I enjoy reading their "About" page and get a glimpse of how it all started.

Success is not glamorous as the media sells it. In fact, It is a lot of time working in the dark. I know this fact first hand.

Game Engine Beginnings. Circa 2013: Improving the rendering engine

I worked over 15,000 hours in developing a 3D game engine. I would wake up at 5 am and work on the engine from 5am-7am before heading to work. I worked on it during my lunch break. And then again after work. And during the weekends, I would work on it for about 16 hours. I wanted to develop a 3D game engine so bad, that it became my life for about three years and a half.

Game Engine Beginnings. March 2014: Improved the engine to render textures.

Throughout this time, the thought of failure kept disturbing my peace. I kept thinking, what if I fail and have nothing to show? What if this is just a waste of time?

Game Engine Beginnings. April 2015: Improved the shadows in the engine

However, I found a way to combat it. I was inspired by Austin Kleon to document the humble beginnings of my game engine. At first, I was against this idea. In my mind, nobody would want to see the progress of my game engine. But Austin made me realize that it is the process, not the end product, that makes our work exciting and inspiring.

Game Engine Beginnings. July 2016: Collision Detection System implemented.

I want to let you know that you are not alone in your struggles. It is OK if your game is not glamorous yet. It is OK if your indie game studio is your room. That is OK if your game only sold ten copies. And there is something powerful about your struggles.

Game Engine Beginnings. Sept 2016: Improved animation and shadows effects.

The finish line of success does not inspire people. It is the road you took to achieve it. It is your suffering, the pain, the obstacles that make your story interesting. It is what gives others strengths to go beyond they thought possible. It is your underdog story that connects us as human beings and inspires us.

Game Engine Beginnings. Aug 2016: Game engine first demo.

So document your humble beginnings. Share photos and videos of your work in progress. Take screenshots of your game. Share pictures of your indie studio; even if it is your room. Write about your struggles and how you overcame them.

Game Engine Beginnings. Dec 2016: Added particle system to the engine.

Don't worry if your game characters look like crap. Don't worry if your game mechanics suck. Don't worry if there are plenty of bugs. It is all OK. As indie game developers, we can all relate and do understand that it is a work in progress.

Game Engine Beginnings. Dec 2016: Tested the engine collision detection capabilities.

A final product is not interesting. It is not inspiring. What is, is your story.

So what is your story?