Spudinski

God dammit, people should stop bitching about this.

Well, when I read the title I was like "what? That little?". Before you even do anything, PHP already populates around 100 variables, and about five times as many constants. But anyway.. If you want efficiency, the easiest way would be(as Dayo hinted) an associative array. Depending on your situation, this could be a few levels deep. Another way to do it is with an ORM interface, but this requires a little bit more work(depending on your framework). The benefit that ORM gives you, is that you have an object that can be executed, manipulated and more. Unlike an array, your output can be dynamic, and callbacks can be set up to perform asynchronous(well almost, it's PHP) actions.

Well dude, better get a decent girl. These STDs are everywhere nowadays...

I don't host with people unless they run the network. I fear a zombie apocalypse where they eat the cables, and the host can't do jack.

What's your budget?

Each serve their own purpose.

I use http://www.oodesign.com/ for designing structures. A very good site, and it contains most of the fancy words programmers use when speaking about OO jargon nowadays.

It's shorter. :P And fixed... :\ But my footer template file isn't displayed... will have to debug that as well. :\

Thanks, but it's standard 4.01. Can't think of any HTML5 features that I used...

It is indeed faster, find/read the sources.

I might have a slightly more efficient method to dealing with this.. You love JavaScript! With things such as this, you'd ideally like to do as much as possible on the client's side. Now, there's a few ways in which to cache/save the data to the user: localStorage, WebSQL and IndexedDB. The support for WebSQL has officially been dropped, which is really sad, since it's much like a real database. My favorite is localStorage, which is supported by almost every browser. What you would do is create the entire map on the server-side once per player, and then pass the map to each client to be cached forever. This is the basic principle is that the entire data set is replicated, and then only individual sub-sets of data is updated when it's actually changed. To change the data is a problem point with PHP, as it's not a thread/daemon that can live forever - once a script has finished executing, it's done. Some people turn to Node.js for this, but it is doable in PHP, but only on *nix where a daemon can be written and ran with success. A kind of event processor will need to be created, which will asyncronously send updates to each client. Sending the data to the client *was* a problem a few years back, since everything was always created in a "ping/pong" fashion(unless you had incredibly large amounts of resources to burn like Facebook). In HTML5 a new feature was introduced, EventSource: in short it's event's sent from the server to the client, without the client having to poll for it via some (ajax) request. Now, the data sets are updated by the server on the backend, and only the "changed" data is sent back to the client(to reduce load, etc.). The thing here is to only send data that has changed. This will produce a sense of "live" data. The client will then have to update their data sets individually, but that isn't your problem anymore, since it's the browsers responsibility. A few problems I can think of: 1. Latency compensation will have to be done(something that's comparable to witchcraft). 2. The amount of work it requires, and the flawless execution it needs(you're server can't have sudden "hickups", or else clients will suffer). 3. Memory leaks, something like this will need to go through thorough testing for leaks(yes, even an 8GB super-ninja system will crash from JavaScript leaks, and I blame IE). The benefits of this: 1. Very efficient if done right. 2. Minimal amount of resources needed for the server-side. 3. Server-side is nearly invisible to the end-user(client). 4. Server-side events are damn awesome.

Haha Lithium.. My website is in Afrikaans, and my audience is either fully Afrikaans or bi-lingual. Furthermore, there are many tools available online to help with translation; Google Chrome has an excellent built-in translator. Though, adding English isn't that much of a deal, it's just a few template files that needs cloning.. but I really don't see the benefit of it.

What's your budget? And do you need a control panel?

Sure, it's something arrays could do, but it would require a lot of manipulation. The overhead on something like this would be insane(depending on user-base/activity). MySQL is designed for this, using date ranges would be much more efficient.

That is half-correct. preg_match() return the number of times a match was found within the given string. preg_match_all() will return the matches, in an additional array referenced to an extra parameter given[preg_match_all(PCRE, string, matches)]. preg_* are functions for dealing with PCRE, or more commonly known as Perl (compatible) regular expressions. "daviD3" will fail on the expression "[a-z0-9]", as inverted.ignore case is not specified - "/[a-z0-9]/i" will match. A few things to read up on: Wikipedia entry for PCRE: http://en.wikipedia.org/wiki/Perl_Compatible_Regular_Expressions PHP PCRE: http://php.net/manual/en/book.pcre.php Cheat Sheet: https://www.cs.washington.edu/education/courses/190m/12sp/cheat-sheets/php-regex-cheat-sheet.pdf

I'll first explain how they work, and then you can guess which is faster. PHP has loose or dynamic typing(some might argue hybrid typing as well). With static/strongly typed programming languages such as C, you will need to definite the "type" of data the variable is going to hold before you utilize it, i.e. "double balance = 2.00". PHP is loosely typed, which means that you do not have to do this - but, there are still a presence of different data types. This is the reason why type-casts exist, to convert data types. I'll do a quick representation of primitive data types, I'll use the number 5. 110101 (Binary, 0b110101 since PHP 5.4) -> 0x53 (Heximal, prepends 0x/X) -> 065 (Octal, prepends a 0) -> 53 (Decimal, will need to be converted using PHP dec2* functions) -> 5 (Integer) -> "5" (String)   Now that we have that out of the way, let's look at comparison operators. PHP defines == as: Equal (after "type juggling"). PHP defines === as: Identical (no "type juggling"). Type juggling is the processes of converting one data type to the other for comparison. With == this is present, so (string) "1" == (int) 1 is TRUE, while (string) "1" === (int) 1 is FALSE. Even (double/float) 1 === (int) is FALSE, as the actual representation of "double 1" is 1.00*. Does this explain it a little bit better?

True, but in today's world of online w/e, there's only one thing to prevent SQL Injections. Validate input, don't convert or strip it! E.g.: preg_match('[a-z0-9]', $x) - if it doesn't validate, don't execute it. It's damn simple, and yet it's always overlooked.

Was that sarcasm? That guy doesn't even grasp the concepts of web security. But I guess I can't blame him - the articles are ancient.

I would say a switch is over-rated here. As I see it, all your numbers are dividable by 1,000 without having fractions: so use an indexed array. E.g.: // array containing a reference map to text // keys doesn't have to be strings, int/double will also work. $exp_vals = array( '1000' => 'Strong', ... '75' => 'Average', '20' => 'Weak' ); if (!($exp % 1000) && array_key_exists($exp, $exp_vals)) echo $exp_vals[$exp]; else echo 'Feeble';

Well, it's the same price as for 40 minutes of my time... Seems like a very reasonable price in my opinion. P.S. Just because an engine is cheap, doesn't mean modifications for it should also be.

I use a few methods, depending on what's needed(and how lazy I am):   Implode: $my_formatted_list = implode(', ', array('Item 1', 'Item 2', 'Item 3')); This method is very useful for displaying a list of data with the additional need for a separator. Mostly database data are aggerated like this. Formatting: $ff = sprintf('Form feed: %c', 0x0C); $formatted = sprintf('Hello %s, you current balance is %.2f', $a::name, $a::balance); Useful, everywhere - though I mostly use it to build up resource strings, like URLs and dsns. Concat: $formatter = 'This is a ma' . 'ssively long' . 'string.';

You might actually get better performance with CPU intensive software on Unix/*nix, which is why Mac is so popular. Just for the fun of it, soft I use: Sublime Text 2 (php procedural, python, javascript) Eclipse (php oop) vim / awk / sed (on server/ssh hot code edits) Subversion Chromium Opera Reminna Node.js / Python / Bash (general purpose) Though, job descriptions are worlds apart.

No flame war, I just wanted to hear the "MY needs" part from you.

Biggest understatement, ever. EA have released titles for Ubuntu. Photoshop works on Ubuntu. Dreamweaver? ****, serious? Use Sublime/Eclipse/Netbeans.

Your test's are invalid. There's no way foreach can be faster than for, and no way sprintf can be faster than concatenation. Also, you count time with loops - even more invalid for *most* tests.