The Marketplace

[Alan]

Well, with the apparent lack of action on games here - I've decided it may be time to create my own. It's a tricky thing creating a new game; as it has to cater for so many different needs; so my first port is a marketplace for modules and templates that can be easily pulled into the game complete with dependencies. The image below is representative of the current work so far. (N.B. module names, brief descriptions, icons, prices and stars are all for my own testing).

The core game itself is a while off completion yet - getting it to work with the complexity of the plugins system is causing some interesting headaches, but it looks very possible.

Once I've got the core working with a basic set of mods - some of which will be dependant on others like the casino games - I need to design a number of templates which may be a task suitable for some of the peeps here - its primarily Bootstrap 4 based with modules having their own specific overrides, graphics, even typefaces etc. Nothing too fancy, but it allows for fantastic customisation.

Anyway, enough rambling ... here's a quick preview of the Marketplace home page (or at least the top part of it!).

Oh and before anybody points it out - yes I'm aware I forgot to correctly name the slots module!

 

[Alan]

The plugin system seems to be a winner - there's a couple of caveats that I'm unsure about; specifically I'm having to use reflection to determine the module's identity, and thus path in order to extend the template paths -- not sure how that will work in an "under load" environment; though it could be replaced with the same type of mechanism I use for auto-loading of custom modules. Routing also looks suspiciously or rather potentially slow (currently using a glob), I suspect that can easily be replaced with a simple custom composer script.

Next stage is to grant plugins the ability to request alterations to the database structure; this will allow things like the addition of attributes on the player record.

The template system is such that while there are a core set of templates; each module will normally extend those to suit. Of course, you are free to override *any* template and in fact you will need to make minor changes to templates when you add certain modules; (ie - positioning links to modules exactly where you want them).

[Alan]

Had a thought last night about using composer as the plugin system -- it's an oddity, but actually it makes a lot of sense in that you are not duplicating code; however I'm a) not sue how to create a "project" for composer, and b) how it would handle things like registration of routes, templates, functions etc. ... Obviously going to have to have another play. Anybody had any experience in this line?

[AdamHull]

This concept looks really good and I look forward to seeing this in action, will there be a way other people except yourself can add items to the market place? 

[Alan]

Well that is the general  idea - what I'm doing is making a very small core "engine", linked to a marketplace that permits developers to upload modules and optionally set prices. The core engine would be free as would a number of the modules on the marketplace.Initially of course, it will be only my own modules however once I've fully designed the core components, I'll open-source it and see if we can get other developers in to help make some of the modules.

 

[AdamHull]

Are you basing it of a already available framework or creating your own, I'm very interested! 

[Alan]

Bit of a mix; I'm using a micro-framework; and adding the elements I need to it: DI, logging, database, image processing etc. It means that the core is very light so problems can be diagnosed more quickly as there is less code to have to hunt through.

[sniko]

• Make it so "modules" need a specific class name and methods to render a view
• Have these "modules"  have a specific namespace setup
• Have the core app register these namespaces on generic routes to load the "modules"

This way you can have composer autoloader in it or the old fashioned FTP with a custom autoloader to have a solution for those who don't use composer too.

It would involve you writing guidelines to creating modules and handling modules but would be a smooth experience to game owners managing them.

 

Edited May 16, 2019 by sniko

[Alan]

Well modules must be openly named, I see no need to restrict people to use *my* naming convention; to a certain extent the same holds true for the namespace. Yes, I suspect modules will need to *extend* an AbstractBaseModule as this will provide them with the necessary facilities (ie access to core services, the render engine etc).

As for registration, I'm thinking something along the lines of a JSON registration file which contains a relative link to the module's routes.php file as well as pointers to any schema change. This would mean that for the system to work I only need load the module's routes.php file during initialisation. Thereafter; only if any of the module's components are need it will be autoloaded.

[Alan]

Bugger ...

The plugins are causing a number of problems in-as-much-as getting the urls in-place; I suspect I may have to document how to manually add urls to your project as it seems just too complex to try and work out where to put them. I guess there is a reasonable case for this in that you may want a module to be only visible for players of level 5 and above for example which just can't be done that I can see. Any thoughts?