Base Framework

[JGadrow]

Ok, I've seen this a LOT around here. People talking about a basic framework. I've actually been kicking around some ideas for quite a while now. So, how about I put them up here and see what everyone thinks. This list isn't meant to be exhaustive, just kinda a high-level view of the goal. We could use this as a planning board for collaboration upon said framework whether it's used for the forum game codestryke detailed in his thread or not. Anyways, here's a few of the things I've written down so far as far as requirements:

Must be object-oriented
The startup must have a very small footprint because it will be loaded every time a page is requested
It should be easy to extend the functionality of the framework by creating a class and registering a module with the framework
Administration should be handled via web interface, it should be very visually oriented and easy to use
It should follow, to the largest extent possible, current web standards (ie: WCAG, CSS, XML, etc.)
Normal PHP errors are to be transformed into ErrorExceptions so that exception handling will be the only error handling within the system
It should provide a shutdown function so that the occurrence of a white page is nearly impossible
Only required functionality should be written, anything else should be coded as an extension module
It should come in two distinct flavors: CGI and CLI (CLI form will basically consist of a server / host setup)
It should have an installer to minimalize headache for end-user setup

There's more, but it's time to get back to work lol.

[codestryke]

We could use this as a planning board for collaboration upon said framework whether it's used for the forum game codestryke detailed in his thread or not.

Ack! Not a game! A frame work, basically you summed it up with...

"Only required functionality should be written, anything else should be coded as an extension module"

Long ago I started creating something called Node Engine, I sort of put it on the back burner but now when I start to create a game I copy over most of the node engine and whala I have an admin panel, login, registration, forgot password, game news, in-game messaging and depending on the game at hand an in game forum.

Must be object-oriented

Personally I think a pure OO game doesn't offer any benefit to a functional one. I like to use OO when the project is large, but most web games are a pretty small code base.

Administration should be handled via web interface, it should be very visually oriented and easy to use

Yup and be in another directory called something like admin and use HTTP_AUTH instead of a form/post, or some type of isadmin check in a player record. I've found both in the past to be very insecure.

It should follow, to the largest extent possible, current web standards (ie: WCAG, CSS, XML, etc.)

I agreed till I saw XML. XML, pretty to look at and understand, pile of dog doodoo when you have to parse it and loop though nodes.
[/quote]

Basically sounds good though. I know you are a proponent of MVC and I would love to see a someone offer up a framework based on that approach. Most of the free web games out there don't use this approach and a lot of newbie coders want to create a game so they download these games and use them as there model to code there game with.

[JGadrow]

Ack! Not a game! A frame work, basically you summed it up with...

No, remember your suggestion that we work on a framework kind of as a forum game? That was what I meant by this comment

Personally I think a pure OO game doesn't offer any benefit to a functional one. I like to use OO when the project is large, but most web games are a pretty small code base.

Well... it's not really a game, more of a framework. And since it requires a bit of abstraction because I intend for this framework to also work reasonably well for about any web-related service (ie: forum, 'basic' website, etc) doing it OO will help allow changes to be made with a minimal headache.

Yup and be in another directory called something like admin and use HTTP_AUTH instead of a form/post, or some type of isadmin check in a player record. I've found both in the past to be very insecure.

Actually, I haven't decided what I want to do about the admin's authentication method yet. However, user authentication will acutally be a modular extension as not every site requires authenticated users. Thus, the authentication should be coded into separate extensions that allow for LDAP, POST, RPC, etc. so that the administrator can decide what is right for their application of the framework.

I agreed till I saw XML. XML, pretty to look at and understand, pile of dog doodoo when you have to parse it and loop though nodes.

Actually, the output will likely be in XML. XSL would also be utilized to transform it into XHTML. This doesn't involve any more processing than is standard for outputting in (x)HTML and is a better method of describing your data output. Also, in case you wanted to port it for use on other devices you're already in a good position to do so.

Basically sounds good though. I know you are a proponent of MVC and I would love to see a someone offer up a framework based on that approach. Most of the free web games out there don't use this approach and a lot of newbie coders want to create a game so they download these games and use them as there model to code there game with.

Agreed. I'd like to give a solid offering to the community built upon 'industrial strength' code. I also intend to put this into my personal code library for usage on my own contract work so you can bet I intend to work very carefully on it

[jannesiera]

Basically sounds good though. I know you are a proponent of MVC and I would love to see a someone offer up a framework based on that approach. Most of the free web games out there don't use this approach and a lot of newbie coders want to create a game so they download these games and use them as there model to code there game with.

Well, I suggest you take a better look at modulargaming. As far as I know it has a good MVC approach.

[Chris]

Absolute must have
- 100% public domain licence (there are tons of other licence engines already)
- it must be clearly stated it is a framework not a game (no game features of any kind included)
- a skeleton, minimalistic design doc describing database structure and prioritized list of features before the coding starts (which is a piece of cake since we have tons of people on this board who already designed such frameworks at least once )

Indifferent
- Must be object-oriented - slightly against, but I can live with it
- It should be easy to extend the functionality of the framework by creating a class and registering a module with the framework - I don't know, I would prefer simplicity, but I could accept this one
- Normal PHP errors are to be transformed into ErrorExceptions so that exception handling will be the only error handling within the system - I do not know, but it sound suspicious Slightly against
- It should come in two distinct flavors: CGI and CLI (CLI form will basically consist of a server / host setup) - No idea what this is about

Against
- Administration should be handled via web interface, it should be very visually oriented and easy to use - against, no need to be easy to use, if you need an easy and visually oriented admin panel your skills sux and your game will be a failure anyway
- It should follow, to the largest extent possible, current web standards (ie: WCAG, CSS, XML, etc.) - strong against, framework should be light, simple and works in majority of browsers, nothing more

[Zeggy]

I like the idea

- Administration should be handled via web interface, it should be very visually oriented and easy to use - against, no need to be easy to use, if you need an easy and visually oriented admin panel your skills sux and your game will be a failure anyway

I think it would be nice to automatically generate a page for each table and have basic CRUD support on that page. This could be simply for admin purposes, or modified into a front-end page. It *could* help speed up development of game features if you use it, and if you don't then you already have a basic admin panel. Like scaffolding, except new files are created that you can edit/customize. This would probably be much easier to implement if you go the OOP way.

[jannesiera]

Admin panel is a must have for if the game is finished, to have an easy control of the game. So I think we should create a basic admin panel - structure so the user can easely extend it with new features.

Modulargaming also has an admin panel. I'm planning on extending it for new features, but it's boring and takes some time, so I'll do it later. But still think it's a must have.

[codestryke]

- Administration should be handled via web interface, it should be very visually oriented and easy to use - against, no need to be easy to use, if you need an easy and visually oriented admin panel your skills sux and your game will be a failure anyway

I think my skills are quite good and my games speak for themselves. I got this way because I'm a programmer, I love to code and I suck at and hate admin'ing games. I've put this task on others close to me that I can trust and they do a hell of a job doing it. To me an admin panel is always a must! That's why my framework includes a skeleton admin panel and I can create a game and have a fully functional admin panel in 3-4 hours work.

My games wouldn't be where they are now without that admin panel. While my admin's were (and still are) taking care of questions, concerns and fixing accounts I was making another feature or making an existing one better. So the players get twice the benefit.

Oh and I can leave for two weeks on vacation with no computer or internet access and still have the same support for my players who are paying for said vacation

[Chris]

Yes, yes, my games code consist of 25% admin panel code as well, and I love them too. But this is a basic framework, made for people who do not have the guts to write the register system on their own Sure, there should be a basic admin panel, but nothing more. When their game grows they can write their own panel.

This is a question what the target audience for the framework is. I assumed it is for the people who started the last competition but could not for some reason release even the simple version of their game. Or people who are just too lazy to deal with login/register/logout routine and want to start coding the "meat" immediately.

[jannesiera]

Yes, yes, my games code consist of 25% admin panel code as well, and I love them too. But this is a basic framework, made for people who do not have the guts to write the register system on their own Sure, there should be a basic admin panel, but nothing more. When their game grows they can write their own panel.

This is a question what the target audience for the framework is. I assumed it is for the people who started the last competition but could not for some reason release even the simple version of their game. Or people who are just too lazy to deal with login/register/logout routine and want to start coding the "meat" immediately.

It doesn't have anything to do with lazyness. The "meat" is the fun part, and why spend time on the boring part if it's available already? Why making it, if you can just copy / paste it? I don't see any advantages in making the register / login / logout from scratch.

It's just important to nuance that for me .

[JGadrow]

There's not 'real' target-audience for this, it's something that I wanted to work on for my own benefit and figured if I can get it up and running and nail down most of the problems, make the system flexible enough to be of use for any sort of site they we could add it to the repository here.

I'll try and work on getting a design document put together sometime soon. Bad timing though as I'm heading up a project here at work and at home I'm getting ready to move my fiancee (I proposed over the weekend) and her children. Busy, busy, busy lol.

[jannesiera]

There's not 'real' target-audience for this, it's something that I wanted to work on for my own benefit and figured if I can get it up and running and nail down most of the problems, make the system flexible enough to be of use for any sort of site they we could add it to the repository here.

I'll try and work on getting a design document put together sometime soon. Bad timing though as I'm heading up a project here at work and at home I'm getting ready to move my fiancee (I proposed over the weekend) and her children. Busy, busy, busy lol.

Ow, congrats! 

[dylan]

Looking at the discussion going on here I figured I should share something I am working on currently. The project is titled Siege Engine. It is written in PHP5 and utilizes the Kohana framework. We are making this base engine generic so it can suit any particular PBBG easily. We are following an aggressive production schedule right now so commits are fairly frequent. Take note: this project was started recently so it is not necessarily a totally-ready-to-launch product yet. We started this project as a base engine to use for our work on a new PBBG and we figured having it open is the best way to ensure security/clarity (nothing like having your code up for public review ) Feel free to stop by and check it out, and let us know if you are interested in becoming a contributor!

Thanks!

Project Git repo >> http://github.com/dylan/siege-engine/tree/master

Our site (military gaming) >> http://www.psyphon.com

[Scion]

Hey Dylan,

Ive been playing around with the Kohana framework too, building the underlying utilities for a game. (to learn kohana, and to use in later game developements where possible)

One thing that has me worried is the end performance, in particular the current lack of support for Op Code Caching... (or alternatively op code cachings lack of support for dynamic loading) Have you considered this yet, if so what is your position.

The other thing that would be really great is if you guys spent a little time actually putting a few wiki pages up with what you intend to have in the framework, what coding guidelines your wanting to follow, how things will be structured, what modules/libraries you plan to use, if you will be including smarty....you know like a road map, with a feature list.

If its a close enough match to what im doing then I might be interested in helping outa bit.

[dylan]

Sweet! Thanks for the suggestions, I will throw them on my todo list and post what I have. We started working so recently and so quickly that I had not taken the time to elaborate things on the public side.

RE: Opcode caching, currently we handle opcode caching as a server side thing. So until things are up and running (and our current tests are pretty zippy) I am not so sure we can give anyone any numbers on performance. Personally either installing xcache on nginx is probably the route for any app we will deploy using this. Right now we are implementing memcache into different parts for the db caching, so it should be pretty smooth.

I hope that helps?

[Delifisek]

Hmmm, it seems framwork histeria is everywhere.

If you are coding your game for 100 people, OK there is no big problem to use a modern php framework for game development.

Please remember, you are game developer. Not unber enterprise CRUD development slave.

Learning framework takes time and learning framwork to generate someting useful takes even more.

Then when you bump to someting you need but your framework designer even doesn't think you have to find solution outside the framework brokes integrity and usefulness of framework.

Using OO looks fancy and costs too much.Real practical use of OO in PHP preveting Object and Variable crashes in large projects.

Perfect php BBG system

• Procedural or uses public static methods for faster access. it shoud not cast objects. they are slow and takes too much memory.
• Avoid XML  and any other kind of overenginereed data formats. processing them too costly
• Avoid Exceptions. They are costly
• to storing non sql data. use php arrays. they are Opcode compatible. SO ? after first load they are stay in memory.
• Avoid SQL much as possible. SQL was primary bottleneck of the syste, If you can cache your data in php or memcached, do it
• Do not use Templates (like smarty). PHP himself was templating system. So use it. all inline php stored in opcode cache too
• Use pseudo MCV. put sql one file, put algorthm one file put output (phtml/temlate) one file. Helps much for code maintaining.
• Follow the Yslow's (a firefox extension) site optimization method to improve your page deliver speed to client
• Use APC, XCache or Zend Accelerator Opcode cache
• If you are using more than one machine. Memcached is yoru friend
• Use mod_deflate for apache.

Regards

[Scion]

all great points, but the reason for chosing a framework is that is allows you to get up and running faster....people have heard me say it before, but you have to use the right tool for the job.

If someone has limited experience or never used any frameworks before then your right a framework might end up being more trouble than its worth, but after youve worked with half a dozen its really not all that hard to pick up a new one....just like languages really...

Im not really sure whats the biff with OO .... I see lots of large scale apps that are OO...thats where php is going, and will get better at. Proper use of polymorphism in objects can substatially reduce the complexity of code being executed....once again, its a case of the right tool for the job.

otherwise i agree with most of what your saying...or atleast the intent.

[codestryke]

to storing non sql data. use php arrays. they are Opcode compatible. SO ? after first load they are stay in memory.

Not just wrong but dead wrong on this point. I don't think you understand what op code is, or you are confusing it with something else. OpCode is the compiled output from the Zend engine. Using OpCode allows PHP to skip the compile step of processing and proceed immediately with execution.

If you allocate an array it is only allocated for that request instance. If you and I hit the same page the array is allocated for my request and for yours. PHP does not (as of v5.0) have shared memory which you are alluding to. Depending on the size of the array it is a lot faster to retrieve the data from the database, it's also (in any instance) less memory intensive as with SQL you are pulling only the data you need.

OpCode is faster but allocating arrays for every request is not optimal unless you run something like IIS which does have shared or global memory that can be shared across the application.

Do not use Templates (like smarty). PHP himself was templating system. So use it. all inline php stored in opcode cache too

PHP itself was NOT a templating engine. PHP was written as an alternative to ASP, hence why it was released on the Windows platform first. It was to be a cleaner more robust language the the psudo BASIC syntax of ASP (which is really wordy). And actually Memcache and Smarty play very well together, I know because I've used them both in the past. Any time you create or use a template engine you are going to sacrifice speed. However what is the benifit for your App? Do you want to be mobile and easily change a template or do you want to sift though PHP code to find that one echo statement that is breaking the template. Do you hire or use a designer that also knows PHP code, probably not. So you have to get the design and then break it up and find all those lovely echo statements to add the HTML code. When it comes to a complex / large game there are just to many pages to edit and changing something graphically can really impeded a release schedule. Programmers, Program. Designers make things pretty and functional and database administrators keep the keys to the data.

Use pseudo MCV. put sql one file, put algorthm one file put output (phtml/temlate) one file. Helps much for code maintaining.

That is not MVC or even close and defiantly not pseudo. You can't kill one section of the 3 (a third) of it and call it pseudo. MVC has never been about speed it's about being able to be agile with any part of the process. When you combine template and code you kill that process. Helps you with coding but doesn't help the designer any. Even if you are one in the same I personally would rather be adding functionality rather then messing around with trying to change a layout with echo statements. Finally too, PHP allows wonderful things however not using SMARTY sort of promotes bad programming standards because Smarty forces you to execute the code fully before outputting to the client


 

[Scion]

to storing non sql data. use php arrays. they are Opcode compatible. SO ? after first load they are stay in memory.

Not just wrong but dead wrong on this point. I don't think you understand what op code is, or you are confusing it with something else. OpCode is the compiled output from the Zend engine. Using OpCode allows PHP to skip the compile step of processing and proceed immediately with execution.

I think he ways refering to using something like APC or memcache to store the array between requests. Well thats what i took from it....(I assume english is not his first language....so i sorta read between the lines a bit)....Not just using them to cache the opcode.

Like everything misuse of a cache can also be harmfull, they hold the data in memory...which is nice and fast....which is why we use them....but if you go and start putting every man and his dog in the cache then your going to fill it up soon enough, aside from the effect of starving the machine of free ram for other usage it means that the OS is going to start swapping the cache out to files....and well...were back into disk reads......hey isnt that what the DB is doing...that is if it hasnt already cached that frequent use data itself?

from my point of view all reference data, belongs in the cache...as does any data that your just using, for example those players that are currently online and being accessed regularly. but the rest is better off sitting in a properly indexed DB...

as for his idea of MVC...well its better than a spaghetti mess of control, view and DB access all mixed up together, but given the choice, id allways start out with proper MVC....Id probably leave it with proper MVC too...

Im using a framework atm...one of the things thats great about it is that i can use as much or as little of it as i want....if i need to i can have some request processing handled by fully customised code and others by the framework....why i would want to write a super optimised solution for user settings management is beyond me, im pretty certain that those functions will remain with 100% framework usage.

[Delifisek]

Thanks for responses, And right English does not my first language.

Templating solution.
test.view.php

contains phtml someting like

Code: [Select]

<div class='test'><?=$test?></div>

running this code

Code: [Select]

ob_start
require('test.view.php');
echo ob_get_clean();


And this phtml format not so much different than smarty.

My codes has one echo, more than 3 years. One echo much faster and much optimized of course you have to spend some php memory.

array caching.

Think ogame or ugame la.

You got universe system by system. When player searches trough universe, in every request ther where lots of sql execution. If you got 10 user you got 10 sql execution for universe search if you got 100 player you got 100 sql execution. Of course there where sql cache and it still connect to sql and sends query.

So I'm saying, store universe sql but after first read store them in the php files in array format. (of course we have implement proper cache control mechanisms).

Ok now I got lots of files (each file for each system 1x1 has one 1x2 has another etc). When player searchs 1x1 it just includes the php file which has only array and if we had opcode cache, system calls this array from memory, Of course you can store in memcached or your preffered opcode shared memory and this model to basic to use. and does not have memcached 1mb slab limit.

Personally I'm against the php frameworks. It confuses me, Probably my english not good enought to understand in every aspect.

And after seeing this

http://talks.php.net/show/drupal08/0

I decide not use any proper OO for game development.

Also, I'm developing a game lets say Similar to Ogame.

I do tons of things. (battle engine (ships act as invidual targets etc), Custom universe (no system or star or planet are same), even jump system (able to ambush a fleet) and big game loop, real real time ) and fail to generate some kind of playable game.

After second try and fail, I realize my problem wasn't good code or ideas.

My problem was, Can't find good framework to support

Game, Frontend, backend, Forum (perhaps wiki) and community.

I believe pbbg must have combined community support.

And I decide to wrote some kind of special CMS/Framework to support all my needs for game development.

Also, Spending 100 dollars per moth was my starting budget limit (barelly enough to having dedicated machnie).
Until game support himsels I can't spend any more.

Because of this, I try and find those template, cache and non oo methods (all tested with xcache and kcachegrind).

Also I'm planning some kind of file packer to concat seperaded mvc files to faster execution on production servers.

Regards