a_bertrand Posted January 24, 2012 Share Posted January 24, 2012 As the development of my game engine is progressing at high rate, I had some discussions with two of the well known figures of McCode mods development (not CB nor Dabs). The first one said he had an hard time with the engine, and wondered why I choose to have for example a menu file on each module directory instead of merging all those entries into a single menu file on the above directory. Also he got somewhat scared by the fact the engine look totally different (from a developer point of view) as McCode. To try to answer those firsts issues, I will explain what were the requirements when I started to code the engine. If you browse the forums, you will see a lot of post from new comers to ask: how do I install script / module X, or I installed it but I get an error on line Y etc. The problem of the current McCode code is that modules are actually not code you can simply drop on the same directory as the other files, you will have usually to modify the database by yourself as well as edit some files to use the new code. For somebody which knows what he do, and if there is at least some explanations of the steps, you should be able to do it in no time, however as we see, many of the new game owners simply have an hard time. To make the installation / upgrade and removal of modules a breeze, I choose to make a really modular design, where modules should NEVER touch existing files. Therefore the installation of a module will basically involve the creation of a new directory, and putting the module files inside. Yet even better, we have an automatic module installation tool directly available from the admin panel, which allows to upload a module directly from your web browser. This will take care of all the setup for you including the creation of the tables. Has convenient this can be for a game owner, of course it needs some time for the module developers to understand how it works. Don't be scared, as I provide also a module creator wizard which will create the directory and files for you after you fill some form, and there will be a wiki manual describing the goal / usage of all the files, class and functions. The second person was somewhat annoyed by all the functions the engine provide like LinkButton, or TableHeader or others, and wonders why I created such functions and even stated that he would prefer to code without them. He went even further stating that a class for the database was not needed and all this makes only life more complicated. To answer this kind of remarks I will try to explain what happened to my own game (NEaB) a couple of years ago. At first NEaB didn't used any of the "Button" or "Table" function, and simply had as many scripts just a mix of HTML and PHP. Then at some point we decided to improve the look and allow to have better buttons as well as letting the player choose the look and feel. For this, we had to go through ALL the files and change all the links / buttons and tables with functions which would allow us to change the HTML for the different themes. As this was a really painful and not-interesting work, I thought it would be much smarter that the engine provides all the functions AT THE BEGINNING, and will allow to ensure that all modules will look the same, and at the same time allows the game owner to change without efforts the look and feel. For the database class, there is even more reasons for it. First of all, I don't know how many of you (beside Danny) tried to actually work with MySQLi, but I can tell you that it is by far not user friendly and it adds loads of functions to call if you want to use it. So the primary goal of the DB class is to make the usage of the MySQLi class a breeze, and ensure therefore that we are safe from stupid SQL injections issues. As you may know, MySQLi allows to pass parameters of the query as additional parameter to the functions which means you don't mix the values and the query in one string. No more "select * from users where id = ".$_GET["id"] Instead you would do something like query("select * from users where id = ?",$_GET["id"]) And then the MySQLi will pass those values in a safe way to the database. A second reason for using a DB class is that the engine provides even a small query profiler, which let you see how many queries a page required, which query has been run and how long they took. That should help you to see where the bottlenecks are. Again, having all those functions without any kind of help would mean it would make the development hard, however I took the time to comment all the classes and functions inside the code itself which means if you use an IDE with code completion (Eclipse PDT, Komodo or others) you will know what the function / class do and how to use it with all the parameters needed. The documentation of the function will be available as well on the wiki site and we will provide there examples of usage too. A long post to try to explain the process / reasons behind some of the decisions of the engine. Of course if there is further questions / remarks / self experiences with cases related, please share ! Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.