Posted april,23rd - 2015
Why do we use our own code and not a prefabricated engine?
To start a multi-disciplinary project like a videogame is difficult. To find and to be able to carry out everything necessary to create a videogame is more so difficult. During my life I have met people able to do absolutely everything needed to create a videogame. But, these people are fairly unique, few and far between. The most common thing is to think of the creation of a videogame as teamwork.
Programming, graphics and sound are the three basic pillars of game realization. Nowadays, the less valued is programming. We found videogames without programmers, videogames full of errors and others where everyone did the same. In the last few years videogames have entered into a democratization which in turn has made easier what had previously been considered the most mechanic part: to program them.
In OXIAB we opted from the very beginning of our Canvaleon project to the realization from the scratch of our own content on the three basic pillars.
Today we want to talk about programming. Our choice was, and will be, the creation of our own code. We believe in absolute control of our project, although it can be argued that the effort needed to do Canvaleon is much greater than if we were to choose a predefined engine. We have five programmers in our team and we still made errors.
Knowing what is going on inside your videogame and why, is immeasurable. It is necessary to achieve an all-round good product. Therefore leaving what is considered the most time consuming part of a videogame in the hands of a software product created by other companies, to which you won’t have access to what it is actually doing, generates insecurity, distrust and decontrol about circumstances, with which you have to belief blindly. And it is important to add that it is you yourself who has to be the one that fits the program and not the other way round.
Many of the things that occur in Canvaleon would be really difficult to do using a prefabricated engine, for example, the camouflage calculation. Generally these engines don’t allow the necessary feedback of graphic data generated by the game itself or the direct access to the machine’s particularities and we would need to have some kind of duality. One instance is, if the game is being executed at the same time by the player and by itself to see if that particular camouflage is effective.
A quality program with a good code design and adequate team formed by knowledgeable people, with informatics knowledge (how they function, etc.) is paramount to the success of the project.
Canvaleon has been created with one particular programming language: C++. C++, It is one of the most universal and most extended programming language. It is very close to what is really happening within the computer processing unit. Its optimization level is so flexible and your control of it is absolute, that you have to be in ultimate control of what you are doing because it can make you panic if you don’t understand what you have to do.
The universality and flexibility of C++ allow us to adapt the videogame to other consoles by making only a few changes. Videogames developers that use other prefabricated programs for their code have told me that what we do in one or two months to make Canvaleon work on a new platform, they obtain the same result by simply paying the price to export it to another company (the one that let them use their prefabricated engine), and with just one click all the work is done. But our answer was unequivocal: If that company disappears, so will do your game.
Canvaleon has a unique code for all platforms. The only thing that changes to be able to execute it by console, computer or mobile phone are the so called Proxy types: five or six files that control the sound, the graphics, the player’s control over the game, the access to other files and the timing. By doing so, the code can’t recognize (and really doesn’t mind recognizing) on which platform it is being executed. This is the key to portability. Working that way we can perfectly have programmers fully focused on the game and assign one to each platform. So we can have experts on the control of a particular console or computer; as the importance can’t be undervalued with knowing what you are working with.
On the following entries of our blog we will be releasing more details about how we have developed Canvaleon on a code’s level. We hope you might find them of interest. Today we just wanted to submit our arguments as to why Canvaleon has been programmed in C++ and not using a game’s maker.
Someone asked us why we do it in C++, and a colleague replied, that we do it in a C++ "because using assembler seemed to us more difficult and more time consuming". What he was trying to say is, that games are programs and as programs they need to be programmed, not only designed, scripted or modulated. Because then it is not a game, it is just a modification of something already in existence and that is not original.