Game Code Structure?

[FirePenguins]

I am curious about how other php game programmers structure their code, specifically their actions (buy, attack, create account, etc...)

Several years ago when I first started writing php games they were very simple and it worked to have a php file for each function (buy, sell, attack) that were included on the appropriate pages.  When the user submitted a form the function would be called with the input.  The function would update the database and echo out the result.

So an example is buy.php has a form whose action="buy.php".  buy.php checks to see if this form has been submitted and calls the function buy_items($input).  buy_items updates the DB and echos "items purchased successfully".  Rest of buy.php runs.

However, as I have taken more computer programming courses and seen more code from other games I've been looking at more objected oriented approaches such as having a Command class and then buy, sell, etc... would extend that class.  There would be one php file that manages the game and creates instances of commands and executes them (a game manager class). In this setup there has to be a command for wait_for_input, to wait for input on forms, and another has to be render_page, to display the appropriate html.  But this approach strikes me as trying too hard to mimic the structure of non-php games where a game manager class is necessary to run the game loop.  Thus it seems too complicated to me.

What code design strategies have worked for you? or what designs have not worked?  Where is a good balance between sophisticated and easy to maintain/change, but not overly complex?  Are there security or reliability concerns that are better addressed by a given design?  Let us discuss! and thanks for any input and advice you share

[133794m3r]

To put it simply, Modularity. Procedural code with Modularity. Various modules do things, and then there is a more 'general' master module handling everything. Code is separated amongst various submodules each doing their own thing and thus extending the core. It's all procedural except the javascript which uses the javascript methods that are built in and those given by juqery/jquery ui but all new code is completely procedural. And also modularity. Once more modularity.

[DV8]

While I'm currently working on my first game, and have never done any game development in the past, I use an object oriented approach. I have several objects, but the most important ones are the Page() class, the Character() class, and the Game() class that ties everything together. I also have several more objects that do specific other things.

It has been suggested on this forum that this isn't the best way to go about things and that it's more trouble than it's worth. While this may be true, I'm comfortable with this type of development, and I'll keep the advice in mind as I go forward.

[Chris]

Evil begone!

The amount of modern high level OOP modularity approach above is so overwhelming that I can only whisper in a faint voice: procedural

[133794m3r]

Evil begone!

The amount of modern high level OOP modularity approach above is so overwhelming that I can only whisper in a faint voice: procedural

Procedrual code can be modular. Look at apache. It's chocked full of modules. The linux kernel is also rather modular. OOP level of abstraction and such i do disagree with. But would you rather have the codebase be one huge monolithic structure? Modularity and procedural programs fit together really well. And seperating bits of code into chunks of things that do their own thing is really good. For example, when you use your OS do you have everything all running at once and have it so that if one thing fails it all dies? No, everything is separated up into various modules so that if one fails not everything goes down. now then, modularity shouldn't be extended to every single thing. But it should be part of your design since it allows for various little systems to do their own thing.

I doubt you have one huge file which holds all of your code chris. I'm sure that, over time, you've broken it up into various files that each do their own thing. Like you have one which handles sql related things like validation/escaping. One that handles your various config files and files such as that all of the way. 

OOP is the evil in this world and i'd prefer if all code was procedural but you cannot stop them. It'll pass though, since right now everyone's going crazy for asynchronous programming via node.js instead of ruby on rails and it's overly OOP approach. Anyway, back to my original statement, not structuring your program is silly, and also insane. Not deciding how things are supposed to go along the way. Designing your program is a must. You need to decide how it's going to look before you ever start coding. Like i imagine that you have designed your database and its schemas before you just started slapping data into it. 

[Zeggy]

I have a class for each page, and a url router that assigns URLs to a class.
The database is also handled like objects, where I have a Player class, Weapon class, etc.

ruby on rails and it's overly OOP approach

Well, everything in ruby is OOP, so of course the web frameworks will be OOP too!

[CygnusX]

I have a class set up for my pages and my user.  The main benefit of this to me is variable management and time savings.  Consider:

make_header($somevar1, $somevar2,..... $somevarn);
make_menu($somevar, $somevar2, .... $somevarn);
..content..
make_footer($somevar, $somevar2,..... $somevarn);

vs.

$Page = new Page;
$Page->set_SomeVar1($somevar1);
$Page->set_SomeVar2($somevar2);
$Page->set_SomeVarn($somevarn);

$Page->make_header();
$Page->make_menu();
..content..
$Page->make_footer();


You can see how much easier the latter is in terms of managing variables.  If the functions, variables, etc change in the first example.... its hell to rework the code.  In classes, its many many times easier.

In addition, I usually have a class that loads all data for a user.  Thus, if I need to see how much gold a user has, I typically do:

$User = new User;
$User->set_UserID($UserID);
$User->load_Standard();

$UserGold = $User->Gold;

This, IMO, it much easier than having to type:
$Result = mysql_query("Select * from Users where UserID = '$UserID' limit 0,1");
if(mysql_num_rows($Result) == 0)
{   exit;    }

$Row = mysql_fetch_array($Result);
$UserGold = $Row['Gold'];

This is especially true if you're looking to obtain lots of information about the user on your form script.  Imagine having to write individual querys to find Gold, NumUnits, NumWeapons, SkillPoints, etc, etc for multiple action="script.php" pages vs. just pulloing it all out of your class which can auto construct the data you require.

PS.  I'd be interested in seeing other critique of this approach.  I am not a CS guru like many others here

[Sim]

I have a class set up for my pages and my user.  The main benefit of this to me is variable management and time savings.  Consider:

make_header($somevar1, $somevar2,..... $somevarn);
make_menu($somevar, $somevar2, .... $somevarn);
..content..
make_footer($somevar, $somevar2,..... $somevarn);

vs.

$Page = new Page;
$Page->set_SomeVar1($somevar1);
$Page->set_SomeVar2($somevar2);
$Page->set_SomeVarn($somevarn);

$Page->make_header();
$Page->make_menu();
..content..
$Page->make_footer();


You can see how much easier the latter is in terms of managing variables.  If the functions, variables, etc change in the first example.... its hell to rework the code.  In classes, its many many times easier.

In addition, I usually have a class that loads all data for a user.  Thus, if I need to see how much gold a user has, I typically do:

$User = new User;
$User->set_UserID($UserID);
$User->load_Standard();

$UserGold = $User->Gold;

This, IMO, it much easier than having to type:
$Result = mysql_query("Select * from Users where UserID = '$UserID' limit 0,1");
if(mysql_num_rows($Result) == 0)
{   exit;    }

$Row = mysql_fetch_array($Result);
$UserGold = $Row['Gold'];

This is especially true if you're looking to obtain lots of information about the user on your form script.  Imagine having to write individual querys to find Gold, NumUnits, NumWeapons, SkillPoints, etc, etc for multiple action="script.php" pages vs. just pulloing it all out of your class which can auto construct the data you require.

PS.  I'd be interested in seeing other critique of this approach.  I am not a CS guru like many others here

Both of your examples are a lot of work.. ;]

You coulda just put this into a function file:

function stuf(somevar1, some var2, sometf)
make_header($somevar1, $somevar2,..... $somevarn);
make_menu($somevar, $somevar2, .... $somevarn);
make_footer($somevar, $somevar2,..... $somevarn);
}
then just do

stuff(3434,3 343 , 343);

$Page = new Page;
$Page->set_SomeVar1($somevar1);
$Page->set_SomeVar2($somevar2);
$Page->set_SomeVarn($somevarn);

$Page->make_header();
$Page->make_menu();
$Page->make_footer();



to something like:


$Page->set_SomeVars($somevar1,$somevar2,$someva3);



but anyways, from my experience of OOP, its mostly functions wrapped around CLASS STUFF.. i havn't gotten into extending classes yet.

[CygnusX]

You could just put this into a function file:

function stuf(somevar1, some var2, sometf)
make_header($somevar1, $somevar2,..... $somevarn);
make_menu($somevar, $somevar2, .... $somevarn);
make_footer($somevar, $somevar2,..... $somevarn);
}
then just do

stuff(3434,3 343 , 343);

This is true...  but lets say suddenly make_Header() requires a 4th or 5th variable due to some Ajax work you're doing.  You could either 1) Define that variable during __construct in your class, or go back to each and every page and re-pass it to make_header().  The latter forces you to be in the business of variable management... the former is a quick and simple fix. 

[Harkins]

FirePenguin: The most standard design right now is Model View Controller (MVC). You have model objects that talk to the database and encapsulate game logic, views that contain only display logic, and controllers that pass data between the two. Additionally, a lot of people are moving to REST style (sometimes called RESTful; stands for Representational State Transfer which is not terribly useful). Each controller provides a standard set of actions that map pretty directly to CRUD - create/report/update/delete.

Ruby on Rails is big into this. I tend to have little-to-no code besides looping constructs in my views, plugins like inherited_resources make it possible to do CRUD controllers in 2-3 lines of code, and the ActiveRecord ORM means models don't fill up with persistence/search code. A lot of folks here like PHP because they feel having less structure means they develop faster; I find that having structure means I write far less code and can iterate faster.

[andrewjbaker]

Check out MVC and Command patterns.

Personally, I've implemented something akin to... http://msdn.microsoft.com/en-us/library/ff647590.aspx

In PHP tho'.

[codestryke]

Going to assume we are in the game itself (ie we've authenticated) and we are also going to assume this is a standard style of game (ie not AJAX driven)

// validates the user session, if not throw them back to login page
include 'accesscontrol.lib.php';

// common.lib.php includes two other includes but basically sets up the game / environment
include 'common.lib.php';

// If I need player information
include 'player.lib.php';

Ok I want to break here for a moment. I've used both player lib as a class and as retrieving a row from the database. The argument of always having to type SQL just to get something like gold is a bit of a stretch I use the get row method and class method, I've seen good reasons to use them and not so good. To me one size does NOT fit all in this scenario and it all comes down to the design of the game and database.

Now back to the code... Here in the code we would process any user input etc etc...

// Hand off any vars to the Smarty Engine
$tpl->assign(array('<var name>' => $var, '<var name>' => $var, 'player' => $player));

// Smarty engine to display page
$tpl->display('player-shop.php');
exit;

The Smarty page for the shop would be something like:

// actually sets up the page header and menu, the menu itself is another template file
{include file="page-header.tpl"}
show shop
{include file="page-footer.tpl"}



This is how my development environment flows. As stated in chat I can have a fully working game skeleton in minutes by using both my libraries and other pre-built ones. With the Smarty engine the presentation layer of the game is completely isolated from the mechanics of the game. If your argument is that you don't like templates etc then you've never really looked into or know how Smarty works.

Everyone is different, especially when it comes to coding style, but this works out very well for our uses. Though we use objects DB / SMARTY I, personally think, that adding a game layer object or whatever would be over objectifying it. Again I think people get do get caught up in the object hype. To me there is no reason to have player-inventory put in the object as I wouldn't use that or any other function like that other then within that page. One of the main ideas behind object and why they are useful is reuse.

[Zeggy]

Your includes are being repeated in every file (which isn't really a big deal, I know).

In my OO approach, I have the same kind of stuff in the constructor of the page object, so simply instantiating the class would automatically check for user authentication, session data, form data, prepare templating, etc. It's all subclassed so I can have public pages that don't bother checking for user authentication, or simple pages that don't require form processing.
So that is one way that using an object for individual pages can be handy.

[Chris]

For example, when you use your OS do you have everything all running at once and have it so that if one thing fails it all dies? No, everything is separated up into various modules so that if one fails not everything goes down.

Now I know what was bothering me for such a long time. You people do not see a difference between coding a website and OS You don't see the difference at all You do want to use all the powerfull tools that were designed to help writing software made by generation of hundreds or thousands of coders and written during not even years by decades. You want to use these same tools and tricks to code a website that is done just by you alone and finished within weeks or months at most.

And the funniest thing is that most people will still say that this is the right thing to do

[CygnusX]

I still say coding with classes speeds up development.... though I'm not quite up to the level of codestryker or zeggy, so I can't speak much about what they do.    

Last night, I decided to combine two of my tables into one to make queries simpler and to optimize my code.  With just a few small changes to the user class, I had made the change and everything was working as normal.  Had I been pulling this information via a function, the problem would have been something like this:

function get_1()
{
  //return array from table 1
}

function get_2()
{
  //return array from table 2
}

Because I had combined the two tables, function get_2 would be obsolete as get_1 now contains all the data.  But instead of going back and reconfiguring all places where I had used function get_2, I was able to make a small change to my class, kept the class variables the same, and volia.  

I guess it could be that I'm just not as smart as other developers, and you guys can keep all the functions, arrays, etc in your head with ease.... or you have your code/design all planned out before the first $ hits the screen....  but for me, thinking of things in terms of objects greatly improves the time it takes to code, my variable management, and sense of what everything is doing.  I hated OOP for years.... and now I'm not sure how I coded without it.

[FirePenguins]

I have also found that using classes saves me time in the long run (not immediately) and makes the rest of my code easier to work with.  I have only used classes for a few objects in the game (player class, input validation class) not the whole game itself.

I have several objects, but the most important ones are the Page() class, the Character() class, and the Game() class that ties everything together.

I would be curious to hear more about how you Game() class ties everything together.  That's an area I'm a little hazy on for the OOP approach.

[Nox]

If there's anything Chris would love it would be this https://github.com/Herzult/SimplePHPEasyPlus

[Chris]

In addition, I usually have a class that loads all data for a user.  Thus, if I need to see how much gold a user has, I typically do:

$User = new User;
$User->set_UserID($UserID);
$User->load_Standard();

$UserGold = $User->Gold;

This, IMO, it much easier than having to type:
$Result = mysql_query("Select * from Users where UserID = '$UserID' limit 0,1");
if(mysql_num_rows($Result) == 0)
{   exit;    }

$Row = mysql_fetch_array($Result);
$UserGold = $Row['Gold'];

Sigh... All this can and should be done (assuming the coder has any sanity points left ) via two lines of code.

Code: [Select]

$Result = mysql_query("Select * from Users where UserID = '$UserID' limit 0,1");
$User = mysql_fetch_array($Result,MYSQL_ASSOC);Take a note that you *always* need the amount of gold since you display it on the page always. So you can just put this query at the global include file and forget...

If there's anything Chris would love it would be this https://github.com/Herzult/SimplePHPEasyPlus Smiley

It would be funny if I were not seeing the coding style of most people exactly like the thing you linked

[CygnusX]

I could also technically do it in two lines if you wish:

$User = new User($UserID);  //constructor method does all the work in your 'include' file
$Gold = $User->Gold;

The advantage over your approach as I could also load all data from another player in the same manor 1 step manor.  IE:

$Enemy = new User($EnemyID);  //again, constructor method does all the work in your 'include' file
$EnemyGold = $User->Gold;

Of course, there is no need to declare $Gold or $EnemyGold as I could take it right out of the class... but at this level, its all preference. 

[lolninja]

==Sorry about the wall of text, dunno if I stayed on topic, I hope I did, though I might have my work work hat on==

Recently I've been forcing myself to write procedural php, and while I can see its merits, I personally prefer a nice object heavy envrioment. Now I know procedural code is faster in some areas, but I like OOP mainly because I can abstract away from places where it is easy to make mistakes.

Now for my reasoning, at work work I work in a team of developers, ranging in skill and general knowledge. Now for an example, seeing as Chris was kind enough to post an example, sql select I'll use that...

Code: [Select]

$Result = mysql_query("Select * from Users where UserID = '$UserID' limit 0,1");
$User = mysql_fetch_array($Result,MYSQL_ASSOC);

Now the problem with this code, in the envrioment where I work is that, the above code assumes the $UserID has been correctly sanitised. Now depending on the developers skill and general knowledge they will hopefully check eiher historical code, or just re-sanitise it them self.

So at work work, if using a procedural envrioment we have to add in house development rules to validate the code, so we have something like...

Code: [Select]

$result = mysql_query(sprintf("SELECT * FROM users WHERE UserId = '%s' LIMIT 0,1", mysql_real_escape_string($UserId)));
$User = mysql...

Now this is all fine, and well, but when we employ a new developer if we have a wide range of these house rules, then its going to take a good long time to get them up to speed.

So with the envrioment we use at work, we have taken the Kohana framework, and integrated the Doctrine ORM, this effectively allows us to never write SQL, to select a single user we do...

Code: [Select]

$User = Doctrine::getTable('Users')->findOneByUserId($UserId);

There is no change this code can be SQL injected, or easily hacked, and if the developer does something wrong, then they get a PHP error, which I'd rather, as they are more easily tracked down by our more experienced developers than typo's in obscure sql operations.

All the above is how we roll at work, and for solo developments it does slow you down to start with, as you have more code to write, and if your using an implementation methodology such as Test-Driven-Development then you have even more code to write. But even though your writing more code, it doesn't generally mean the deliverable will take longer to finish. As unit-tests make debugging code much easier, tracking down minor logic errors should be a case of running your tests.

Now a common issue people rise, if the support of Procedural code, and the putting down of OOP is scaleability, you either want to get a couple more concurrent connects, which lets you handle more active users, or you want to have super fast executing sql.

I'll gloss over the SQL first, as it easier, with an ORM the outputted SQL is as optimal as handwritten, but it takes less time to write.

Code: [Select]

// SQL
SELECT
FROM User u
LEFT JOIN Gold as g ON u.id = gold.user_id
LEFT JOIN Stats as s ON u.id = stats.user_id
...

//Doctrine
Doctrine_Query()->create()
  ->select('User u, u.Gold g, u.Stats s')
...

You also get the benefit of easier updates, for example...

Code: [Select]

$winner = Doctrine::getTable('User')->getOneByUsername('oop');
$loser = Doctrine::getTable('User')->getOneByUsername('procedural');

$winnings = min($loser->Gold->amount, 50);
$winner->Gold->amount += $winnings;
$loser->Gold->amount -= $winnings;

$winner->save();
$loser->save();

Now onto scalability, this is where OOP gets a kick in the face, all this time saving code can use an absolute ton of memory, to get Doctrine and Kohana parsed into memory, and selecting some data your talking 3-4MB minimum, now thats using a standard, un-opcache primed PHP/Apache based envrioment. Drop in something like APC, eAccelerator or XCache and those numbers drop to be closer to procedural code.

So the main argument for using OOP based code is development time, writing an overly complex select on a normalised database might take say 15-20 minutes, but the same using raw sql would take say 20-25 minutes, now say you want to update some record, thats another 15-20 minutes of validation etc for the procedural implementation, with an ORM its seconds.

Right thats enough of wall of text.

*edit*
Noticed some typos after posting, and corrected them, though there are likely countless more I've not noticed :S

*edit 2*
Altered the last Doctrine example so it works this time, I forgot in the SQL example gold was a linked table, so added $winner->Gold->amount to access the amount value stored in the gold table, original code was...

Code: [Select]

$winner->gold += 50;
$loser->gold -= 50;

*edit 3*
Just realised I forgot to make a point, and the point I was trying to make, no idea how successfully, is that OOP vs Procedural the resulting code is pretty close in terms of memory usage speed and the like. But if you take the time to get completely comfortable with OOP you'll not look back, unless your entirely fixated on execution speed, but thats not a bad thing, it'll just take a bit longer in the long run, possibly.

At the end of the day roll with that you find easier, I learnt to program using Java, so I'm going to find OOP more natural, others learnt on Basic and C, so find procedural code more to there linking.

The goal should be to make awesome browser games, or anything else your making. Once the game is done, the users aren't going to care if there user account is accessed via methods or functions, If there character is accessed by an ORM, or raw SQL, just that it works, and it kicks bottom

So I say, make code happen, and do it the way that feels right to you, I just happen to like me some OOP

[Mutant]

I don't code PHP (I've dabbled in the distant past), but just wanted to weigh in on the side of ORMs. My game makes extremely heavy use of an ORM. I rarely write SQL at all (only in the very rare case when I need to optimise something). Without an ORM, the complexity of what I'm doing would become impossible to manage, and I'd end up with an unmaintainable mess.

"But it's slower than writing the SQL yourself" I hear you cry. True, but you probably need to read up on "premature optimisation" (the root of all evil, doncha know). For the vast majority of cases (this includes your case), an ORM is "fast enough". And that's all I care about. A good ORM will let you optimise where you need to, which usually turns out to be a surprisingly small number of cases. If you really want ultra fast, then PHP is really the wrong language anyway. You want C... or better yet assembler. Just trying maintaining that after a few months though. The point is, ease of maintenance trumps performance in 99.9% of cases. (And, of course, there's the SQL injection issue that so many PHP apps are vulnerable to... there are other ways around that of course, but an ORM will take care of that stuff for you).

I could probably repeat the above for MVC frameworks.

I guess if you're doing something relatively simple, and you have really slow servers (and are never likely to upgrade), you may want to go for something less abstracted. But as soon as you start doing something complex, getting your head around higher levels of abstraction becomes almost necessary, at least if you want to be able to work on something relatively stable and easy to change.