Modular Gaming - Free PHP Game Framework

[Curtis]

Modular Gaming is an open source browser game framework based on Kohana 3.x. Licensed under the New BSD license, can be used for personal or commercial purposes.

Modular Gaming can be used to speed up the development of your game(s), by giving you the basic core elements of your game.

Using the event/hook system you can easily modify the core and include modules that can be installed by simply adding them to the bootstrap.
Features

    * Highly secure
    * Extremely lightweight
    * Uses the (H)MVC pattern
    * 100% UTF-8 compatible
    * Loosely coupled architecture
    * Extremely easy to extend

Game related features

    * Authentication/authorisation - (Register/Login/Roles/Settings)
    * Communication - Messages, Forum and Groups.
    * Characters
    * Pets
    * Battle system
    * Shop and Inventory system
    * Traveling between zones.
    * Zones - shops/npcs/monsters in different zones.

Requirements

    * PHP 5.2.3 or higher.
    * MySQL 5.x or higher.
    * Apache with Mod_Rewrite (for nice urls)


More information at http://modulargaming.com

[133794m3r]

  `password` varchar(64) DEFAULT NULL,

yeah your thing is clearly NOT secure.

i stopped looking at it right there. I think you have to/should learn more about database security. Also everything as myisam? It's going to kill performance on a great deal of it. I didn't look at the code just the sql dump file to see how 'Highly secure' it really was.

[Delifisek]

WoW, one damn table field and your project blown, because of what ?

It was open source you uber 3l33t l4mer. If you know better, patch it...

[lolninja]

  `password` varchar(64) DEFAULT NULL,

Whats wrong with this? I normally store my password in a varchar and I've never had any problems?

[dsheroh]

  `password` varchar(64) DEFAULT NULL,

Whats wrong with this? I normally store my password in a varchar and I've never had any problems?

I suspect the issue he had is that NULL passwords are allowed by the database.

Or maybe it's that the field name implies that it's the actual plaintext password that's being stored, rather than a hash of the password, although that seems like a bit of a stretch to assume - I usually name my field "password" rather than "passhash", even though it is hashed.  (Of course, as a marginal performance tweak, hashed password fields should generally be CHAR rather than VARCHAR, since the hash will always be the same length.)

[lolninja]

I suspect the issue he had is that NULL passwords are allowed by the database.

Ah yeah, sorry dumb 5 minutes The project uses Kohana so if it uses the built in auth stuff it should be hashing it with a cyclic salt, so in theory its all good

And the CHAR vs VARCHAR is a good catch +1 me thinks

[Delifisek]

If Passwords stored on varchar means not secure,

TYPO3, Simple Machines Forum (yea our forum uses too), Magento (popular e-commerce suite),  wordpress, egroupware

Not secure too...

[SpaceDoG]

What's the diff between varchar and char?

[Chris]

char is fixed size. If all fields are fixed size the table is fixed size. If table is fixed size it is trivial to calculate where next row starts (sum size of all fields * number of row). If you know where the next row starts it is much faster to find that row and the table is faster.

It works this way with MYISAM, INNODB uses more twisted system and everything there is in reality varchar.

[lolninja]

If Passwords stored on varchar means not secure,

TYPO3, Simple Machines Forum (yea our forum uses too), Magento (popular e-commerce suite),  wordpress, egroupware

Not secure too...

So if your not using a varchar what do you use? I fail to see why a varchar would be any more or less secure than a char? I mean if you have a cyclic salt based on a hidden cycle pattern which is somehow tied to the account through some obscure method then its pretty much impossible for a hacker to just change the stored password to steal an account, unless they have access to your source, then you have other far more pressing issues.

From my experience most site hacks exploit the database, either through sql injection on an improperly validated query, or by hacking phpmyadmin. Neither of which give them access to your script files, so a hacker wouldn't be able to just generate a new password because there is a fundamental bit of missing data, ie the salt, yes its possible to try and reverse engineer the salting mechanic but realistic its going to take a long long time to do.

Maybe there is something glaringly obvious I'm missing and if so I would love to be enlightened, but to my current understanding your perfectly fine just saving the password, once hashed salted, in either a VARCHAR or CHAR data type.

[Delifisek]

Well, problem is not varchar, char or even a security bug. Problem is, FUD ing  the project owner.

If you find a problem, send him a patch, or detailed info about oribken or help to fix it. This is the spirit of the Open Source.

And

My next project will use login via facebook, google, msn etc... I will not implement any more user authentication systems for other than administrative accounts.

[133794m3r]

WoW, one damn table field and your project blown, because of what ?

It was open source you uber 3l33t l4mer. If you know better, patch it...

just because you get all pissy becuase allowing for null passwords as an option and also making it appear to be a 64character password which as far as i know is no decent hashing algorithm proper, and i didn't want to dig through it tall. I'm too busy doing my own things, and this is the name that i've been using ever since i finally decided to have a singular online presence. I don't know what this kohona thing is, and it's probably OO by nature as most things are now a days and i refuse to touch OO code.

[Curtis]

Yes it does use a salted hash for the password, using Kohana Auth module, so I assume it is secure.

Thanks for the advice about using char if it is a fixed size, I missed that when looking over the structure.

Personally I prefer OOP and believe it is cleaner/easier to understand but everyone is entitled to their own opinion

[Delifisek]

WoW, one damn table field and your project blown, because of what ?

It was open source you uber 3l33t l4mer. If you know better, patch it...

just because you get all pissy becuase allowing for null passwords as an option and also making it appear to be a 64character password which as far as i know is no decent hashing algorithm proper, and i didn't want to dig through it tall. I'm too busy doing my own things, and this is the name that i've been using ever since i finally decided to have a singular online presence. I don't know what this kohona thing is, and it's probably OO by nature as most things are now a days and i refuse to touch OO code.

It was not my project you ub3r 3l33t c0d3r.... And so what ? What if his password system was not so good ? Is entire game development all about the how we saving passwords ?Also even he got best password saving option entire universe, you did not use his framework/library because of your non OO vision.

So why you bashing his project.

This guy try to do something and share with you... Show some respect...

[Curtis]

I just checked the GIT and noticed it already had char(50), NOT NULL. You must of looked at the older download?

I've released a new version just now which has newer code (a lot been happening in GIT but not made a release since May...)

[Curtis]

New version released which uses InnoDB for all tables.

I decided to change them all from MyISAM after a bit of reading online and doing a few benchmarks.

[Chris]

New version released which uses InnoDB for all tables.

I decided to change them all from MyISAM after a bit of reading online and doing a few benchmarks.

Bad choice for a framework.

InnoDB needs more memory to run properly and people who use frameworks usually run on crappy hardware.
InnoDB requires proper setting of buffers and people who use frameworks usually don't have access to hardware settings nor have the skills to do it properly (setting too high buffers is very bad, too low is bad too).
InnoDB is more prone to nobish mistakes and people who use frameworks usually have low skills (how many of them will remember/know to rewrite the count(*) part of the code?).

MyISAM is much more fit for frameworks.

[Marek]

Bad choice for a framework.

InnoDB needs more memory to run properly and people who use frameworks usually run on crappy hardware.
InnoDB requires proper setting of buffers and people who use frameworks usually don't have access to hardware settings nor have the skills to do it properly (setting too high buffers is very bad, too low is bad too).
InnoDB is more prone to nobish mistakes and people who use frameworks usually have low skills (how many of them will remember/know to rewrite the count(*) part of the code?).

MyISAM is much more fit for frameworks.

I don't agree about your assumptions about people who run frameworks. I would think that advanced developers use frameworks more often (like Symfony and Kohana), while beginners are more likely to avoid them (because of the learning curve).

Do you have any references to back up your claims about InnoDB? I've never heard of your memory and buffer claims before.

[Copy112]

InnoDB needs more memory to run properly and people who use frameworks usually run on crappy hardware.

Now, i would be glad to know where you got that information from.
Mozilla uses kohana in atleast 1 of their live sites.
Most large companies/organisations develop their own frameworks after a while, for faster development instead of rewriting everything from scratch.

Frameworkes are often the result of a collection of code you develop during a time and reuse in several projects.

[Sunchaser]

Being an heavy user of cakephp and kohana, i agree with nano and copy112.

Why reinventing the wheel? framework builders are skilled developers, i would like to have their knowledge and experience.

Working with framework let you concentrate more on the game functionalities.

[Curtis]

InnoDB needs more memory to run properly and people who use frameworks usually run on crappy hardware.

Not sure where you got that idea from, do you have any data backing this up? I was under the impression people using frameworks in general know what they are doing, a framework such as this is different to as an example mccodes.

InnoDB requires proper setting of buffers and people who use frameworks usually don't have access to hardware settings nor have the skills to do it properly (setting too high buffers is very bad, too low is bad too).

From my benchmarks it worked better than MyISAM with no changes. With the proper my.cnf changes it did work %50 better though to be fair. Only thing InnoDB is bad at by default is tables which are mainly using just writing or just reading.

InnoDB is more prone to nobish mistakes and people who use frameworks usually have low skills (how many of them will remember/know to rewrite the count(*) part of the code?).

No need to rewrite the count part of the code seeing as Jelly is used for database CRUD.

MyISAM is much more fit for frameworks.

In my opinion after testing I believe InnoDB is better but everyone is entitled to their own opinion

Seeing as Drupal 7 now uses it by default I can't see why there would be a problem.

[Chris]

Do you have any references to back up your claims about InnoDB? I've never heard of your memory and buffer claims before.

Browse sql server finetuning forums, the InnoDB topics far outweight MyISAM topics when it comes to buffers.

"Innodb tables are much more sensitive to buffer size compared to MyISAM. MyISAM may work kind of OK with default key_buffer_size even with large data set but it will crawl with default innodb_buffer_pool_size. " http://www.mysqlperformanceblog.com/2006/09/29/what-to-tune-in-mysql-server-after-installation/

framework builders are skilled developers

And McDonald makes healthy food
Do you really want to say that the bunch of random people who wrote the open source phpBB forum are skilled? Looking at these you will just catch bad coding habits

As for other things... Well, I'm not really interested in this discussion, so I don't want spend time to defend my point of view, especially when it is obviously correct... To be experienced you have to write something as simple as framework or forum software or portal or CMS. And after you wrote it you have it and you don't need any framework made by someone else. Therefore the biggest audience for frameworks are people who don't have the skills to write one or don't have the time (but if you don't have the time to write your own framework you won't have the time to learn programming as well so the end result is the same as if you lacked skill).

Anyway, I don't really care what majority think, I just wanted to say that you should not use frameworks if you can afford to write one yourself. This will pay off later. The skill acquired when writing you own framework will be very useful later. Jumping right away to coding the tasty game features will be faster at the beginning but sooner or later you will have to pay for this. It's not a big deal if you are making games as a hobby, but if you want to pursue a career of full time game dev you should avoid these.

[Curtis]

http://thefjord.org/2010/08/22/myisam-vs-innodb/

Bit of a better read regarding a comparison seeing as that one is from 2010 and you linked to a post in 2006.

[aerosuidae]

InnoDB needs more memory to run properly ...

Agreed.  You don't get ACID for free.

InnoDB requires proper setting of buffers and people who use frameworks usually don't have access to hardware settings nor have the skills to do it properly (setting too high buffers is very bad, too low is bad too).

Agreed, but worth noting:

• MyISAM has a whole lot of configurable buffers too, and some suffer from similar to high/low settings
• Hardware and MySQL config settings access aren't really needed. Any user can set custom buffer values with SET SESSION <buffer> = <value>;

InnoDB is more prone to nobish mistakes and people who use frameworks usually have low skills (how many of them will remember/know to rewrite the count(*) part of the code?).

Not really agreed You can use the same simple queries on MyISAM and InnoDB unchanged and it works fine; no need to go fully transactional or foreign key mad. COUNT(*) is only a problem on very large datasets.. but yeah, its a catch.

MyISAM is much more fit for frameworks.

Too broad a statement IMO. It is entirely dependent on the traffic and schema of the app.

Anyway one of the most important things InnoDB brings is reliable crash recovery.  For those using MyISAM, get your local friendly DBA to set this variable for you:

http://dev.mysql.com/doc/refman/5.1/en/server-options.html#option_mysqld_myisam-recover

Also, we should note that MyISAM is obsolescent.  Future MySQL releases will use a storage engine called "Maria" (or possibly renamed "Aria") to replace MyISAM.  It is somewhere between InnoDB and MyISAM: a transactional engine with crash recovery like InnoDB but fast and light weight like MyISAM.

MySQL 5.5 already sets InnoDB as the default engine.  It says something about MyISAM, doesn't it, that it is going to be dropped by the MySQL dev team?

[aerosuidae]

Incidentally, another couple tidbits on InnoDB:

MySQL 5.1 comes with the InnoDB Plugin, which is a re-architected version of the old built-in monolithic InnoDB code and includes patches written by Google. The new plugin is typically benchmarking a good bit faster than the old InnoDB, so don't hesitate to test it and migrate your games if you can.

MySQL 5.5 beta is out with InnoDB 1.1, which is apparently even faster again.  Not many people using 5.5 in production though, so jury is still out.

MyISAM's speed advantage is not so great anymore.  That is not a slur on MyISAM either; it's just that technology gets outdated.