Upcoming Engine

[Guest]

Yo,

So as a side project I am working on an open source game engine, PHP, SQL based. I am currently wanting opinions on what features YOU would like to see. The main features are listed below.

CORE FEATURES

Main

• News & Updates
  
• Property/Domination
  

Actions

• Crimes (reworked views)
  
• Extortion
  
• Travel
  
• Hospital
  

Communications

• Forums - Threads, posts, pagination, lock/delete/stick thread, seperate sticky section on the forums
  
• Online users
  

Personal

• Your stats
  
• Your profile
  
• Notepad
  
• View profile
  
• Basic inventory along with the base for shops
  

EXTRA

• Simple template system
  
• Separate ACP to the game
  
• Everything is configurable from; countries, crimes, crime categorys, propertys.
  
• View profile
  

 

PLANNED FEATURES FOR 0.2

Main

• Game statistics
  
• Referrals
  
• Helpdesk
  

Actions

• GTA's
  

Communications

• Inbox - Send/Recieve
  

Shops

• Bank
  
• Bullet factory
  
• Weapon store
  
• Armor store
  

 

All I have left to do in V1 is do the ACP, dashboard, settings, users, secret thing and crimes

Currently requires PHP 5.1 and MySQLi. Coded/programmed in OO, all ideas and criticism (if there is any at this stage) is welcome

Though this may sound like any other engine, some features I have missed off on purpose which will hopefully make the engine stand out from other free engines, set up will require minimal to zero coding. I am hoping to have a release within a month if the designer can get the ACP design done in time.

Edited September 7, 2012 by Guest

[Djkanna]

I'd like to know what open source license you'll be releasing this under?

Best of luck with it. :)

[Guest]

I'd like to know what open source license you'll be releasing this under?

Best of luck with it. :)

I have yet to research what benefits each license gives, Pretty much as long as there is Powered By ENGINE I am really not fussed, or even http://sam.zoy.org/wtfpl/ though for support on the forums you require your game to have "powered by ENGINE" else your support ticket/thread will just be denied.

[a_bertrand]

I'm not a big fan of the MVC pattern. I know lately (or not so lately) this is like a marketing word, but honestly I find it most of the time overkill and annoying. Why? Because you need 3 classes (the model, the controller and the view), you don't replace completely the use of a template engine and make the code harder to debug.

Overall the only benefit I could see of this design is in case you need multiple "views" of the same content, for example one mobile and one full, or for example a soap interface too. This design would let you keep then the model and the controller intact while just changing the views. Beside for such cases, I hardly see a benefit.

For your engine, you should think what kind of customer you are aiming at:

- The newbies which knows nearly nothing about PHP and web games, for which the easiest the engine is (installation, upgrades, management and ideally the coding too) the best it is.

- The advanced developers, which usually needs only a framework and may are not even interested in a game engine. This will be your harder audience as they may think they can do it better, and in any case doing all by themselves will let them have full control.

So if you are aiming at the first kind of customer, I would strongly suggest to keep the code as simple as possible and not go for some fancy design pattern.

[Guest]

I'm not a big fan of the MVC pattern. I know lately (or not so lately) this is like a marketing word, but honestly I find it most of the time overkill and annoying. Why? Because you need 3 classes (the model, the controller and the view), you don't replace completely the use of a template engine and make the code harder to debug.

Overall the only benefit I could see of this design is in case you need multiple "views" of the same content, for example one mobile and one full, or for example a soap interface too. This design would let you keep then the model and the controller intact while just changing the views. Beside for such cases, I hardly see a benefit.

For your engine, you should think what kind of customer you are aiming at:

- The newbies which knows nearly nothing about PHP and web games, for which the easiest the engine is (installation, upgrades, management and ideally the coding too) the best it is.

- The advanced developers, which usually needs only a framework and may are not even interested in a game engine. This will be your harder audience as they may think they can do it better, and in any case doing all by themselves will let them have full control.

So if you are aiming at the first kind of customer, I would strongly suggest to keep the code as simple as possible and not go for some fancy design pattern.

Thanks for your reply, I went to an interview last week and they asked various things, what is the MVC, I was like the framework? And they said it isn't just a framework but a model, so my understanding of it is

Views -> Little PHP and pure HTML kind of like a simple template system

Model -> These are the classes

Controller ->This page initiates any specific classes, includes the model and does the submitting of forms and validation.

Is that a wrong understanding of it? Because I see that as pretty simple :s.

My user base will be anyone, yes it's broad but in time it will develop for the more advanced with plugin managers ect, module management. But at first I want it to be the most configurable engine out there. Though this may sound complicated it isn't. Giving an example is hard due to I don't want to give ideas away to others ^.^. But think of it as for an example vbulletin, there groups, you can choose to access or deny access to anything, there is a fair bit of configuration but with some preset groups it makes it easy.

Do you understand what i'm getting at or am I confusing you and myself? haha

[a_bertrand]

MVC is not a library it's a design pattern. Huge difference.

The model is a pure Object Oriented representation of the data. It DO NOT have any code logic normally. It's like purely the result of the ORB. So you will usually need some DB abstraction layer which is able to load / save objects for it.

The controller is what manipulates the model, for example edit fields, add new values, or remove them. Checks for the passwords, email, or whatever are inside the controller. However it doesn't know anything about the forms as that's the job of the view.

View is a little bit more than HTML and a simple template system. It could even use jquery to have the dynamic feeling or more. The view is basically FULLY responsible of how some action / content is displayed and handled by the user.

Beside that I must admit I didn't really understand what you want to do but ok, fine. More engines == more choices and could actually improve the quality of the exiting if a programmer pick some ideas ;)

[Guest]

MVC is not a library it's a design pattern. Huge difference.

The model is a pure Object Oriented representation of the data. It DO NOT have any code logic normally. It's like purely the result of the ORB. So you will usually need some DB abstraction layer which is able to load / save objects for it.

The controller is what manipulates the model, for example edit fields, add new values, or remove them. Checks for the passwords, email, or whatever are inside the controller. However it doesn't know anything about the forms as that's the job of the view.

View is a little bit more than HTML and a simple template system. It could even use jquery to have the dynamic feeling or more. The view is basically FULLY responsible of how some action / content is displayed and handled by the user.

Beside that I must admit I didn't really understand what you want to do but ok, fine. More engines == more choices and could actually improve the quality of the exiting if a programmer pick some ideas ;)

I must have had the totally wrong idea of the pattern then, oops :(. But yes maybe it will give others ideas as well :)

[Guest]

UPDATE: Added Inventory with the tables required for items and item categorys, buy/sell/description/equipable/item_defence/item_attack stats

Currently working on: Dynamic menus

UPDATE: Finished Dynamic menus, now loaded from the database, option to hide as well as have drop down menus ect

Currently working on: Shops

This will be fun, loading everything dynamically from the DB.

Edited September 5, 2012 by Guest

[HauntedDawg]

MVC, no.

Are you using proper indexing on your table's?

Are you using proper methods of secure authentication?

What Engine are your DB table's using?

Will there be JavaScript goodness?

[Guest]

Are you using proper indexing on your table's? Not come across that

Are you using proper methods of secure authentication? What do you mean? As in login and such? If so yes

What Engine are your DB table's using? MySQLi as stated above

Will there be JavaScript goodness? As in what NWE has? If so no

[a_bertrand]

Secure authentication, maybe he intend as the password will never travel in plain text, so some sort of hash sent from the browser page to the server or something similar. Yet the only true secure one I know is HTTPS or... at least the more secure than some JS code you could come yourself. Maybe security expert Octarine could find a better and safer way, but for me HTTPS is really the easiest / most secure you could get. BTW SSL keys are not so expensive starting at like 8$ a year for a comodo SSL key... I mean, come on if you can't afford that...

[Guest]

Secure authentication, maybe he intend as the password will never travel in plain text, so some sort of hash sent from the browser page to the server or something similar. Yet the only true secure one I know is HTTPS or... at least the more secure than some JS code you could come yourself. Maybe security expert Octarine could find a better and safer way, but for me HTTPS is really the easiest / most secure you could get. BTW SSL keys are not so expensive starting at like 8$ a year for a comodo SSL key... I mean, come on if you can't afford that...

True but that would require each user to buy a separate certificate correct? The password is encrypted. The login part requiring the password is posted below

 

$username = $io->i($_POST['username']);
$password = $io->i($_POST['password']);

if($login->checkUsername($username)){
	$password = $user->encryptPassword($password, $user->get('', $username, 'salt'));

	if($login->checkLogin($username, $password)){

 

Would you have any other recommendations in changing it at all?

[a_bertrand]

Yes each user should have their own HTTPS / SSL key.

The issue is not only on the database level that you store the password encrypted which is mostly a security if somebody steal your table somehow, but I believe here the issue is the transfer from the web page to the web server which sends at least once (if you don't store the password in the cookie for example) the password in plain text over internet.

[HauntedDawg]

Are you using proper indexing on your table's? Not come across that

You should soon.

 

What Engine are your DB table's using? MySQLi as stated above

Table Type, not Class. There's MyISAM, InnoDB, MRG_MyISAM, CSV, Blackhole, memory, archive (Some of the basics)

[Guest]

Yes each user should have their own HTTPS / SSL key.

The issue is not only on the database level that you store the password encrypted which is mostly a security if somebody steal your table somehow, but I believe here the issue is the transfer from the web page to the web server which sends at least once (if you don't store the password in the cookie for example) the password in plain text over internet.

If someone stole the database, it password uses the same encryption method as vbulletin. Web page to web server, Once the password is received from the forum it is hashed then compared to the database one.

 

You should soon.

 

Table Type, not Class. There's MyISAM, InnoDB, MRG_MyISAM, CSV, Blackhole, memory, archive (Some of the basics)

I'll have to look into the indexing, table type is InnoDB. Things like this i never knew that they mattered.

[Octarine]

Users in an ideal world need only identify themselves by something unique; commonly their username or email address; therefore surely the password entry and/or password storage scheme has no bearing on the actual game itself. No matter what you do, people are going to be looking at the game, not how securely you've designed your password system - and any revenue is equally going to be generated from the game itself, not the security system.

Hashing the password against a short-lifetime server-generated token prior to POST'ing back would seem a decent solution with a fallback to plain-text for non-js users (which shouldn't be a problem given the fact its a game). HTTPS can be added if you think it will help but somehow I doubt its addition would result in more revenue.

[Guest]

What I meant by the SSL is that each person who used the engine would have to buy it, by it being open source i was trying to reduce the costs. Once it's released as 0.1 in a week or two I am sure you can see more in depth on how things work. :)

[Guest]

Dev release will be once I have done some of the admin panel as currently you can't do anything ^.^

[Guest]

== -- Delayed due to unforeseen circumstances -- ==

[Dave]

Closed at request.