I ran into this recently and I thought I’d save a few people the trouble of excessive googliness. There are a few reasons why your errors won’t show up on your site.
I’ll keep this short and sweet!
sudo apt-get update && sudo apt-get install --only-upgrade bash
Recently I’ve seen a lot of people using while loops to retrieve a single record. You only need to loop through your result set when you expect to get more than one row of data returned. If you use a loop even when you only expect one value back from your query then you’re wasting your server’s resources because the PHP interpreter has to do more work to process a loop than it does to return a single result. This assumes you have already connected to the database and have a table to work with.
Let’s say we have a table called members with the following information:
----------------------------------------------------- | ID | NAME | EMAIL | LOGGED_ON | ----------------------------------------------------- | 1 | Sam Jones | sjones@gmail.com | False | ----------------------------------------------------- | 2 | Dee Walter | deeman@gmail.com | True | ----------------------------------------------------- | 3 | John Doe | jdoe@gmail.com | False | ----------------------------------------------------- | 4 | Lisa Wells | lwells@gmail.com | True | -----------------------------------------------------
Now our ID field is an auto_increment and unique. That means no two members will have the same ID number. It’s guaranteed that looking up a member by their ID number will return 1 record or no results. 1 record if a member with that ID number is found and no records if a member with that ID doesn’t exist. Anytime you expect to get 1 or fewer records returned there’s no reason to use a loop, instead find the row directly:
<?php
//run the query
$result = mysqli_query($dbh, "SELECT * FROM members WHERE id='1'")
or die (mysqli_error($dbh));
//fetch the results
$row = mysqli_fetch_array($result);
//display the results
echo $row['id'] . " " . $row['name'] . " " . $row['email'] . " " . $row['logged_on'];
?>
Since we know there is only one member with the ID equal to 1 we can run our query, fetch the results and then display the data returned from the result.
Now let’s say we want to display ALL of our members. In this situation we know our members table will have zero or more records at any time, especially as new members are added in the future. In this case we expect our result will always, with the exception of when we add our first member, have one or more member in it. Here it’s appropriate to use a loop to display the data.
<?php
//run the query
$loop = mysqli_query($dbh, "SELECT * FROM members")
or die (mysqli_error($dbh));
while ($row = mysqli_fetch_array($loop))
{
echo $row['id'] . " " . $row['name'] . " " . $row['email'] . " " . $row['logged_on'] . "<br/>";
}
?>
So, here’s the low down on how to setup a connection to a MySQL database using MySQLi and PHP. This will also make sure your login information is protected. First, you’ll need a database, PHP, and a place to host your files. Once you have those you’re ready to go. Don’t have a hosting provider? No problem, check out XAMPP.
1) You want your login for your database to be protected. That means you want the file to reside in a non-public part of your website. For instance, in most hosting places when you go to view all of your files you know to put them in the public_html folder or the www folder or the index folder. Your database login needs to be in the directory ABOVE your public folder. For most people this is called home, the name of your website, or even the root directory.
2) Create a file called dbh.php (or any other name that suits your fancy) in your home/root directory. That means if people navigate your website they’ll never be able to accidentally access this information because your home/root directory has different chmod permissions (711) then your public_html directory (750).
3) Now you need to write the code to make the actual connection to the database in dbh.php.
<?php
/**
* replace things with { } curly brackets with the appropriate information
* including the curly brackets! don't leave those in there...
* You'll use your database handler ($dbh) when you run your queries
**/
//connect to the server
$dbh = mysqli_connect("localhost", "{username}", "{password}", "{database}")
or die ('cannot connect to database because ' . mysqli_connect_error());
?>
4) That’s it for the code to connect! Short and sweet. Now the question is how to get it in all your files.
5) Create a file in your public_html folder called index.php. You want this file to be publicly accessible to anyone. Put this inside of it:
<?php
/**
* include your database connection from a protected directory
* by include it from the directory above (../) where this file is
**/
include('../dbh.php');
//do all the rest of your usual php coding here
echo "connection successful!";
?>
If you don’t get an error message when you try to view this php script then you know your include was successful. Now there’s no chance someone can get the login and password for your database and you can access it from your php files like you normally would AND you don’t have to rewrite the connection statement at the top of EVERY php page you make.
Nifty huh?
This is a technique where you build a working version of your game and play it before you ever release the game to market. So you may be asking yourself, how does this reduce my game development costs if I need a working version of the game before I can play test it? The answer is simple: create your working game in an inexpensive medium. So what if your marketable game is going to have cutting edge graphics or high poly 3D models or even stunning visual effects that require months of complex mathematics and physics and matrices — with play testing you can see how well your core gameplay and mechanics work (or fail) without any of those expensive bells or whistles and in a lot less time.
I generally break this down into six steps.
Start by sitting down and thinking about the core components of your game. How does your game work? How could someone play a physical manifestation of your game?
Now that you know all of the components of the game you’ll need to write up a set of rules. Your play testers will use these so they know how they should play your game. If you can’t identify any rules for your game then you’ve found your first problem — you don’t actually have a game yet and it’s time to go back to the drawing board.
Not all games need materials but you probably will even if it’s as simple as a few pencils and some blank sheets of paper. It’s time to visit a local arts and crafts store and buy whatever you think is necessary for someone to play a simplified version of your game — be creative to keep your costs low (ie use paper balls instead of nerf balls). You will need enough materials for at least one person to play your game. If your game is multiplayer you may need to invest a bit more so you can let multiple people play together.
This is pretty much self explanatory but it’s also a really deep topic. Other than to say the more people who you can get to play the better, I’ll come back to it later.
You can take a lot away from a play testing session. Did your player(s) struggle understanding the rules or sticking to the rules because they weren’t clearly defined or they didn’t make sense. Did your players pick up the general mechanics and components of the game quickly? Even if you have a negative response to both of these areas don’t panic! This is a good indication that your rules need improvement and that other materials or aids might be required (ie tutorials) before your players can really understand what you’re asking them to do.
Ultimately your play testing session boils down to did your player(s) enjoy themselves? Was it so long and complex that they quickly lost interest or was it so fast paced that they finished almost as soon as they started? Where they laughing and becoming immersed in the experience or growing frustrated and angry? Did they feel sufficiently challenged? Some people find asking their play testers questions about their experience helpful and often times will ask for them to fill out a feedback sheet or a survey when they’re done. Personally I prefer just watching people play. Watching someone play your game will give you a huge amount of feedback and target areas in need of improvement all without breaking the bank. Remember that it’s okay to go back to square one and start again if your play testers don’t have a positive response to your game. The best part about negative feedback is that it just saved you from spending lots of time, energy, resources and money on a game no one thinks is fun.
Okay so I kind of glazed over step four because I wanted to devote a whole section to it. I always start play testing with my target audience. Your target audience should be the age range and gender you believe your game will most appeal to. For instance, if I was intending to make a game for young children I would keep in mind their computer skills, the types of devices they are most likely to play on, their hand-eye coordination, their cognitive abilities in understanding themes, stereotypes and story development. Each of these would be adjusted based upon what I expect young children would find fun and amusing — loud silly noises, larger buttons, brighter colors, less text to read and rules introduced slowly and over time to build complexity.
Now your target age range and genders should all be play testers — but so should other groups. Don’t limit yourself to only your target audience or your may miss gaining valuable insight to how people play and interpret your game. Although you may be designing a game for young children you may find that your target audience has missed it’s mark when the young children have only negative responses to your play testing sessions while a different group of play testers find your game the perfect mix of fun and challenging entertainment.
There’s also a matter of size to consider. Even if your game is single player, what happens when you ask two people to play it together? This may (or may not) change your game dynamics for the better or lead you in a completely different direction that ends up becoming something much more successful that what you had to start with. In that same vein, push the limits. What happens if you triple the number of players who are playing at a time? This is especially important for multiplayer games where your play testers end up being on a small segment of the number of players who will ultimately be playing your game. You might suddenly find your calculations for resource management fall short when your player base grows exponentially or that the influx of players completely changes the pace and feel of the game — for good or for bad.
Game development is expensive so do yourself a favor and make sure you’re spending your money on a game that’s going to help you reap the rewards of all your hard work. Play testing is easy and much cheaper than spending your money on a game that’s only going to flop when it hits the market.
Online Game Development 