Indie-Resource.com

I'm thinking of setting up an open source framework specially for PHP games.

I've helped develop a few games in the past and I know quite a lot of you guys make your own as well.

PHP is if I dare say a pretty messy language, everyone has their own way of developing so it would be good to develop a framework to make things more strict, however a framework like Zend is too big and CI just won't cut it for a game.

It would be good to know what you would like to see the framework do, maybe contribute to the architecture of it and if you want to write a few classes feel free I would say .

The thing with a specified framework like that is that you need a database, almost by default. This in itself is not a big problem, but modular design like Zend or even Ci is required for this. This means there should be connectors for all kinds of databases, be it MySQL, Pg, MSSQL or even a noSQL solution.

Next up is the fact that every game is different in it`s roots. An application framework like Ci has a base class and a base purpose. Writing web applications. A game framework requires a base class as well as a base purpose of a game, and this is were it goes south, since every game is different. Be it an RPG, an MMO, an MMORPG, RTS et cetera.

However, i don`t dislike the idea, but writing a framework is futile. Building a comprehensive library, however, doesn`t have to. If we can somehow develop a guide as to how a class library would look like, we can start delegating functionality. for instance, adding a map generator, or a clickable action grid.

Same goes for javascript specific functionality. But there`s much to take in to consideration.

Thanks for the reply.

I like the way you pointed out a few problems, and this is pretty much the whole point of this framework. To overcome them. We need to put our minds together and think up the technologies.

Two of the main points of the framework would be to handle users and to work fast, so of course it will need to make use of databases. However I'd like to see one game that doesn't (please don't post one ). This is a specialized framework after all. The nice thing about databases is they all use SQL, and as long as it's developed with basic functionality, in theory any database should be easy to implement.

I'll start writing a basic controller and see how this turns out. Once I have this finished we can see how we can make it so we could have pretty much any game style running from it.

An idea for the JavaScript would probably come out best to develop an API like back-end that produces JSON. This could then either be read by a simple JavaScript like framework or the back-end PHP framework. But again this is only an idea.

Well, if you are going trough with it, then i`ll help out wherever i can

If speed is going to be an issue, caching should be enabled too. But, if you are going to write a framework, i think it`s best to setup an installation for the framework. One where you specify all required settings, for both SQL database ( where there should be a couple of connectors available ) as well as port/username/pass etc.

Secondly, the javascript can be returned as JSON, however, i think the fastest way to utilize javascript is not pure JSON and js, but using a library like jQuery. It handles JSON very well, and due to it`s accesability easily maintainable and scalable. Like i said, it handles JSON very well, but it can handle all kinds of requests, like POST, GET JSON, JSONP and plain text ( be it html or xml or whatever).

Which is my next thing: if we are going to use JS for, let`s say, a map, i think plain text is fastest. Iterating trough JSON objects takes more time/CPU then one dump of HTML. PHP is faster in parsing plain then transforming it to JSON first and then let js solve the JSON object.

So if a map should be generated, plain would be the fastest way to go.

Now, for the rest, like you said, SQL is a common language, so i agree that should not be that hard to implement, If a proper connector and connection have been made, a good SQL query for inserting proper tables etc should be sufficient.

Now, for the next thing: what tables should be set? Because creating a authorize part is not that hard, but what comes next is. Perhaps, during the install give the option to select what kind of game they want to build? Or maybe a list of items pre defined by the framework? Options should include:

Map / Grid if true, what size? ( default )
Armor / Weapon sets
Player sets, if so what kind of options should be available?
Is an inventory required? if so, how many data types will it handle?
etc etc etc.

But, yeah this could work.

Now, for the routing part, how do you want to implement that? I believe a routing schema should be made, either by database control or trough YAML/XML files.

Also, kinda reminds me, if you allowe Armor sets to be set, then the framework should create CRUD classes for those, which all inherit from the main Application class i suppose, or the Model object. It should be preset, so are acccesible trough the entire application.

Security is going to be a tough issue to. All $_POST/GET/JSON requests should ALWAYS be filtered, which can be CPU intensive, especially if you allow certain characters. So all datatypes must be predefined, creating a heck of a good input filter (s) for datatypes. This is the ideal situation, however, if datatypes are not predefined, then all input has to be filtered trough everything.

Anyway, i can rattle all night about this, im going to stop right here. lol.

Kind regards

one thing I am glad I did with my tutorials is use the same coding all the way through and use the same queries. When someone has a issue and posts here I can just about fix it without even looking at their queries. Like $playerinfo3['variable'];
Making these type of queries constant will help a ton..

Like a inventory system where things are interchangable but use a basic query system that doesn't change. Have the player queries standard with functions that each pull player data accordingly...

example

Function playerstats() pulls all players stats only, like strength dexterity or whatever, the owner defines the stats in a constants file. Build a easy to use combat system with PVP that can be modified but is uniform no matter what the attack. So if I want it to not use strength as a modifier it changes across PVP, PVE, ect...

Building something like this will enable us to release our games and nearly drag and drop and interchange other parts of games built with the framework. So say callan creates a stable system for raising horses, and i create a battle system for mounts, we could trade and nearly drop them straight in our different games.

I love the idea of a framework and would donate to this idea.

Yeah, totally!

But before ever programming one class / function list, there should be a API structure. One where all rules and stuff goes into. There should also be naming conventions et cetera. Database structures, table name prefixes, inherited function lists, and above all: it should be easy to use. It`s like making a puzzle, all the pieces must fit together

That's the fun part

Chris, did you already start writing out some guide lines what so ever?

I started writing a bit of controller but am going to rethink it tomorrow. Off school this week, so have nothing much else to do

Any luck so far? It usually is not a good way to just dive in something when programming. First, get an application structure done. A simple UML diagram for class inheritance for example. The core system should have some base classes ready, every time a new load is taking place. Also, the core application class ( or controller ) should be a singleton. That way, you can start using the global $App in all subsequent sub classes as well as user defined or non-inherenting classes.

Either way, you should come up with a diagram first. Because the technical part is probably the easy part. The logic ( be it game-logic or application-logic ) is the hard part.