ezRPG Tutorial 1.0.2

[Aventro]

Architecture

Today we are going to take a look at the architecture in ezRPG. It's kinda important we get to learn how ezRPG works so we can effectively write code to our game upon it.

One key rule in writing successful web applications in PHP is to separate the business logic from presentation logic. Now let's see if ezRPG does that.

File Structure

admin/

 

Because administration may have many different tasks, the developers of ezRPG decided to give it's own directory instead of sharing the same directory as the game modules uses. ezRPG brings some helping functions to make sure that only players with Administration access may enter the panel.

hooks/

 

Hooks provide a way for you to add code which will run in certain parts of the ezRPG core code, or at certain times. It actually exists quite a good tutorial about this on the old repository ezRPG used. You can have a look here:

https://code.google.com/p/ezrpg/wiki/UsingHooks

It's basically an event system. Running when the web application is started and could also be run when you want to. We're going to use Hooks later on in this series to make some changes to the Login.

lib/

 

This directory contains libraries, external libraries, helpers (functions). Every external library is placed in the ext/ sub-directory. The naming convention is quite simple. It's using a prefix on what it is.

 

(Type) -> (Name) -> (Example)

• A class -> class.name.php -> class.hooks.php
  
  
• An exception -> exception.name.php
  
  
• An function (helper) -> func.name.php
  
  

 

 

Yeah, you get it!

modules/

 

The module directory! This is the place where we store every module (game task). A module could be a Profile which displays a User profile and allows a User to edit it's own profile.

Let's take a look at the AccountSettings one. Every module has it's own directory named after what the module should be called. Make sure you take a name that a module isn't already using. This is actually quite a problem which is solved in a later version of ezRPG (being in development as when I'm writing this).

In the AccountSettings directory we have a index.php file. This is the module itself. If we just take a look in the file we can see it's a feature that allows a user to change his password. So if we would want to extend this, a good way would to put stuff that changes the account (player) in this module, like changing email, gender, age. Now I guess a Profile module could instead display a Profile! But we could also have permissions on what information a profile must and must not display. Still confused? Don't worry the next tutorial is all going to be about writing a module.

smarty/

 

ezRPG uses the template library Smarty which gives us flexible and good template files. Within this directory we can find two directories, templates/ one are the one you will use mostly all the time when playing with the templates. The templates_c stores cached templates, which increases the performance of Smarty.

static/

 

Front-end assets. CSS files, images, etc.

 

bar.php - This files is basically a file outputting a bar image.

captcha.php - Outputting a captcha image, but also setting a session containing the "code" displayed on the image. Used on registration. Personally, I don't like this because this captcha things can be a bit tricky and the bots keep breaking them. We would be better off using reCaptcha.

config.php - The configuration file, contains database details, constants needed, i.e. A global configuration file where you put all your configuration needed.

index.php - Starting the web application. Executes the module a User request and than display a response.

init.php - Bootstrapping ezRPG.

lib.php - ezRPG uses no autoloader but instead we need to require all classes, helpers we want to use in our application. You do that here.

 

The cycle

I don't expect you to understand every single word above, but it should give you the information you need for starters. Before moving on I'd like to summary (pretty much) what's going on in a ezRPG application.

When a player enter our application the index.php is executed, we call the bootstrap file (init.php) which sets up every essential thing needed in our application (includes configuration, database connection, template configuration etc). Once this is done, it's time to figure out what the player is actually requesting we do that by parsing the URL, which gives us a module, containing a game feature/task or whatever, i.e. the Profile (perhaps the player is looking to display the admin profile, in that case the URL might look like this index.php?m=Profile&username=admin). The module does what's it's supposed to do and then display a template or whatever. Lastly it calls a footer hook (this is the time where you can do stuff like close the database connection or something like that).

 

Until next time... Now when you understand the architecture a bit better, make a copy and experiment. That's the way to go! Perhaps you could manage to turn on error reporting on your own, because that could be useful in our next tutorial! ;) (Hint: config)

[Guest]

Nice explanation, helped explain a couple of things, I wish you luck with it.