a_bertrand

Thanks guys ;)

[ATTACH=CONFIG]931[/ATTACH] Comments feedback questions are welcome.

If you didn't saw it before, read it till the end: http://makegames.tumblr.com/post/1136623767/finishing-a-game Honestly, by seeing many developers or people which want to develop, I fell this blog post resumes all the pitfall and issues new comers will find. Read carefully "1. CHOOSE AN IDEA WITH POTENTIAL" as... many pick ideas which are way above their knowledge or simply are copy cat of what already exists.

Great work Kyle! Congratz!

Well, I doubt it transform the original queries to prepared statements right? And for me that should be done to avoid SQL injection for example.

Well converting from one lib to the other is one thing but how do you do it? Prepare statement? Or real_escape? Dare to show an example?

Seems a bit the output of this tutorial: http://cgcookie.com/blender/category/tutorials/rendering/page/3/ Your island is too spiky to look real, or at least the trees would never be on such slope. Overall it's not bad but doesn't really look natural.

Ok updated clans to incorporate the cancel request. Thanks for sharing Illusions.

Namespace is mainly used to avoid conflicts in class names. Imagine your game have a "Map" class, it should not conflict with whatever else framework class called "Map" but which makes something totally different. By using a namespace you ensure that whatever is inside this namespace can re-use class names and yet still be accessible. If you don't work with other people code, you may never have any issues, but as soon as you mix your code with frameworks you will end up needing it ;)

I will try to incorporate this change in the official mod tomorrow. Thanks Illusions for sharing it!

It's indeed conversation. I'm anyhow thinking / planning a new project (mad project? ) myself, where load of content will be player generated content. So I do have some thinking in that direction too. If you want I could privately discuss it.

There is a couple of issues with player owned areas. From my own experience with NEaB I learned that: - Players will try to cheat, so for example, put low prices to grab things nearly for free - Content may risk to be very repetitive as they will simply do always the same things specially if you can't really do much as player - Broken content, as player don't finish well their things. - Typo, bad texts, foreign language or whatever - Copyrighted picture (if you allow picture upload) So hoping that your players will actually put content in your game... it's possible but will not be totally be free. You will have to have some sort of review. Also I don't know exactly what you will allow to do, as otherwise everyone will have just the same features in their area, maybe just with a different text.

Hahaha, that's not what I was writing, nor thinking. If you look back he's trying to sell a license he has, I don't think he want to buy something else.

Doesn't seems to have much market sadly.

Mmm I see, so you as player create a new area, and then decide what's there, right?

Clans now have clans stats for example to store some money, or honor or number of kills or whatever YOU decide. To demonstrate the usage, I created a simple clans_bank (if I remember right Kyle created one too, right? Sorry if it's a double). Basically you create a stat inside the install.sql: replace into clans_stats_types(name) values('Bank');   After that you can call: <?php SetClanStat($memberOf, "Bank",100); $value=GetClanStat($memberOf, "Bank");

But would that "facility" be visible by others as well? And if yes, could somebody else remove what you added? Also how many locations would you have? Infinite? A small set?

Ok let's skip this difference (which for me is not so small), now imagine I want to make a 3D renderer, or a sound synth.... Is MVC the correct pattern? no. Same applies on any website. Are all the website the same? From google, to a webshop, to the embeded webserver you may find on your ADSL router. Have all those the same requirements? No, not really. Sure they do all have to generate some data your browser will understand (being html, flash or whatever else). So why would one pattern always find it's way? Now if you talk about what people talk today as web development (specially with PHP), sure you will hear about frameworks, MVC, and maybe some jQuery or other integration. It tends to be a bit over used in my opinion, where people starts to miss what exactly is the goal of this design pattern. And for sure BlackScorp I wasn't talking about rewriting McCodes. I'm not the owner of that script, not I'm in any mean interested in it. It was just a friendly discussion about who and why use MVC.

Ideally the controller should not have anything to do with the view, otherwise forget any dependency injection.... or make things harder. Ideally, when the model updates, the view is "triggered" or waked up because the view is an observer of the model. Yet, don't know how each PHP frameworks handle those, pretty much safe that it's hardly doable as all the "event" model which would be involved is somewhat missing in PHP. SO when you say the controller does the view (directly or not) it's wrong and you would end up with a different design pattern than the MVC. Nothing pointy or technical discussion here, it's really what MVC is, 3 different and distinct objects which talk to each others, each of which is in charge of a particular process. Check back the wiki link I added at first, it gives exactly the definition of the MVC pattern. Yet if in the framework you use it's not like that, then it's an issue of the framework which doesn't implement a true MVC but something... different. Bad? no, simply different.

MVC is not a standard, it's just a design pattern don't mix the 2. It's like saying that you can always use eggs in any receipt, that would be wrong. Don't take it badly it doesn't mean MVC is not good, simply it's not a "fit always" solution. On the other side, OO programming could always fit. BTW The controller SHOULD NOT display, it's the back from the view. That means it receive the interactions from the user. And... No you should not implement the logic of the actions on the model as it would be wrong again. Also, indeed when I made the PHP certification it was still PHP 4, but guess what, MVC is MUCH older than this ;)

Some people seems to think that you should always use MVC in any project. I'm somewhat more moderated toward it. Let's try to discuss it, and no it is not related to my engine ;) First of all what is MVC, as I wonder if all those stating MVC is a requirement really understand it well: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller MVC is composed of at least 3 distinct pieces which should also implemented in at least 3 different classes: - A model (which is basically a storage or a memory representation of your data (an array key / value pair is not enough usually)) - A controller which let you do actions on the model, for example edit some data - A viewer which reads the data from the model and prepare or generate the GUI for the user to work with. On the view side you could even use a template engine on top of it, so that would be again split in 2 parts. What is important to note is that the 3 are loosely linked together, which means that you should and must be able to work only on one of them at a time, while working with pseudo versions of the others for example to test the different pieces of software. MVC is a design pattern, which is not dependent of the language, tools or where you will use it. A design pattern is like a general idea that can be reused, not really a cook list but just a general idea of what could be done to solve a given problem. Where this design pattern is useful: - It let you test the pieces of your software in separated ways, for example it's quiet doable to test a model and a controller, while the view which is related to a GUI usually can be more tricky to test in an automated way. So where you need to have automatic tests running for example in big software houses, or in fields where even a small bug can have huge effects (for example medical field), automatic testing is a must. (Unit testing is part of that for example) - When you may offer more than one interface to the same data, for example a web interface and a standalone GUI, and maybe even a mobile GUI, an MVC will help as you will re-use 2 of the 3 parts. Actually, you may even run the view on one server while the model and the controller may run on another one. When is this design pattern overkill: - Here it's question of taste and personal opinion. If you just do a small guest book for you personal site maybe it's not really useful. Again personal opinion. Ruby on rail works basically on MVC as well as many PHP framework offer some form (some times very good one) of MVC to use. So no you don't need to start from scratch yourself most of the time. Personally, I would use it only if I have a requierment for it, as it has an overhead in term of work to invest, specially if you don't use some good framework. And unless I need / implement unit tests, system tests, integration tests... or I need multiple "views" of the same content, I hardly see a benefit from it. But again, personal opinion. I'm more of the KISS principle (Keep It Simple Stupid) where small code means less chances of bugs. So what's your opinion about it and where do you use it if you do, or why don't you use it if you don't ?

It's not a bad idea. Just check what are exactly the performances hit with it compared to none and how much it will bring you. Keep in mind, more code in PHP (to load even if not executed) means slower to run. At least if you don't use bytecode caching for example with APC. Now many frameworks offer also caching in form some or a complete page on the server, and therefore not executing your whole script each time. I would personally check multiple frameworks and see, based on what I want to do, which one fit my requirements better. There is currently many frameworks offering different features like ORB, MVC or yet other design patterns ready to be used.

Well... Here I don't agree, not all run with "new" versions of PHP. Actually if you run on older Cent OS or old Redhat based distro you could still have PHP 5.1, so always running for the latest and greatest may cut you out of some. Yet I would say MySQLi is a must, and old MySQL is really to be avoided. But that's personal opinion.

Not too bad for a first one. Colors do mix well together, and it's quiet pleasant to look at.

It's quiet nice indeed. I'm pretty sure they took the midi info to generate the animation.