Well, it has been a hell of a month in my advanced programming class at the master, I've got to admit that it has been really hard for me to keep up with all the stuff needed to learn to create something very simple as an Arkanoid. You don't know what that is? Well, I guess this image will explain pretty much all.
It's so ancient that I can even think that Julius Cesar had it on its chambers on a big flat TV powered by donkeys running on a mill to produce electricity (LOL.. of course not, but it is a very old game).
Mechanic is simple, use the palette to destroy each bricks by bouncing the ball against them and when all bricks are gone you complete the level and start a new one with more bricks and different disposition. So, what's difficult on that? Well, it turns out that everything you you see on your computer screen is drawn as Triangles. Wait! What? Yes, those little tree vertex monsters that use to torment us at highschool with trigonometry are in charge of rendering all you see on the screen, including text and circles (yes, circles). So all of this I learned in this course, it has been super didactic and fun but it requires a lot of time, effort, studying and over all: try-and-error. There's a particular thing about OpenGL, although it let you do pretty much anything when it fails it simply draws nothing but a big flat dark screen and shows no error at all so finding the root cause is like trying to prove aliens exist, so yeah.. it is hard. That's why graphic programming requires some serious skills. You must understand pretty well linear algebra as well as basic algebra since all the models, rendering, effects and camera's are basically based on transforms where you took a point in space, apply a transform matrix and voila! you suddenly have that model located in 3D space with a correct perspective and an impeccable lightning setting over it. And where is all of this writing going? I just wanted to highlight that C++ combined with OpenGL and focused on graphic programming is an ability a game developer should count on when things are complicated by using a standard tool like Unity, Construct or Game Makers. There will be times were the game engine will not suit at all what your are pursuing and the answer may be in developing even your own game engine or writing code in C++ just to solve that particular game mechanics thus rendering it on the screen. Here's where the Arkanoid comes in play, this little game has a lot of work behind because basically I created the geometry with coords and then place them in the graphic card to be rendered and of course, don't forget about lightning. It uses a Phong lighting model that was implemented in a shader and then compiled and linked also in the graphic card. I'm very proud of having completed this little game and my journey just started, this is a very small part of what regards a Game Engine architecture and to be honest, I'm not planning on going full c++ for my career but what I will definitely take from this practice and will love to go deeper is GLSL to code Shaders. They are pretty much in charge of all the interpretation of how your models are rendered and you can achieve some really cool effects either by translating vertex points or by applying textures to give a more realistic appearance.
Architecture. What's the monster behind those bricks?
This is the class diagram of the game and it's completely enhanceable but I used YAGNI approach to solve this (You Ain't Gonna Need It). Just developed what was necessary, no general design but instead a more focused and specialized approach to make this functional and efficient, I'm not creating the next Unity or Unreal engines.
What went right in this game?
I was able to encapsulate OpenGL's functions into a class to easy my drawings and model uploadings to speed the development process.
Game is completely playable and memory doesn't leak (that's big!)
5 levels were implemented where bricks are increased when you advance in game.
Model rendering, game updates and collisions are executed just when they are needed. I limited collision evaluation only for required objects (ball and bricks). Ball is in charge of knowing to what it is colliding to, and bricks should know when they should be destroyed. Although now I believe ball could have done pretty much everything.
What went wrong?
My normals somehow are not working correctly, you may notice it by flying the camera behind the scene and realizing bricks have light were it should be shadows.
Collisions are not correct, sometimes they collide as supposed sometimes they don't. I believe it has to do with the game architecture since it considers milliseconds to trigger each game update instead of ticks. I decided to go this way to avoid hardware speed dependency.
This probably will only work on a computer with an Nvidia graphic card, not sure about running on any other hardware.
I had to implement a sphere but some problems came up therefore I decided to go full cubes. I need to review what the problem is and resolve it.
The architecture isn't the best but solves the problem, it can be revisited for a better design but the development was done rushing to reach due date (school due date).
It has been a didacting experience and most important, I believe I understand better why game engines work in the way they do so I feel a little more capable of taking right decisions when making a video game knowing what's going to happen behind scenes.
If you want to try running it you can download it from the following link, no install required just run it.
http://imcsw.com/CGameDemos/Arkanoid/04MVID_d.exe
Thanks for the reading, hope you enjoyed it.
-Tristan MX