breaking up data amongst tables or joining them into one huge one.

[133794m3r]

One thing that I am currently doing is looking over my chat system, since there are multiple 'chats' I'm trying to decide if i should use a few tables rather than one table with an additional parameter saying which 'channel' the chat came from so that it's more easily kept clean especially when doing lookups on it for when the ajax sees if there's new messages.

So then which way of doing this is better in the long run? I've already set it up so that each table is it's own file, and I am primarily concerned with stability, and consistency. Speed is also a big factor but right now making it fast is not one of the biggest ideals for me since I'm basically delegating that to just using mariadb's xtradb version of innodb and other such patches written by people who are a lot smarter than I am and hoping that allows it to run 'fast enough'. If the speed improvement is enough then I'll do whichever will result in better performance and also more reliability in my databases.

[chrisjenkinson]

Why is it more clean to have one table per chat channel than have one table for all channels and a "channel_id" column for messages? If you have an index on that column getting new messages will be quick. It will also be easier to create additional channels, and to modify in the future as you only have to alter 1 schema rather than X (where X is the number of channels you have).

[Zeggy]

I'd go with just one table with id, user id, message, and channel.

Have you considered maybe using a memory table or memcache?

For my own chat, I also use this idea of multiple channels. I use javascript push to push chat messages directly from user to users. The chat messages are not stored on my server at all.

You could use a javascript push service like http://www.pubnub.com/ for this. Although, for this particular use, I wouldn't recommend pubnub. Their pricing model doesn't encourage  mass broadcast apps. There are many other javascript push services though.

[footyfish]

Have you considered maybe using a memory table or memcache?

For my own chat, I also use this idea of multiple channels. I use javascript push to push chat messages directly from user to users. The chat messages are not stored on my server at all.

+1

Why are you worried about consistency? In an ideal world this would be nice ofc. If a users own messages appear on their screen (without being sent to-and from from server) every user has an inconsistent view anyway (plus you make the client "smart" and do more work). Users will favour your chat for availability over consistency. If replies are slow this is a pain; or they cant enter chat (you seem worried about this before you start). This means you want speed, which you can provide given you know what your users want (current chat). So store current chat in memory and forget after X - once its unwanted.

Then there is the right tool for the job. You aren't storing data for later, you are pushing/sending it live. Maybe try something like rabbitmq, aka a message bus. It'll be more stable (you wanted stability) than your webapp and will deal with the set up you want with some config (like strict ordering (if you must), suppling recent messages). Then you can copy some code from a client example and profit. There is a lot of OSS magic out there .

[codestryke]

This is one of those things that you will need to test yourself to see what the results are.

If you put it all in one table with an index on the channel then every line written to chat will need to update said index which is a write operation. Writes always take time and if your chat is very active this could be a performance bottle neck.

Each of my games uses chat and each go to a separate table and I haven't had any major performance problems.

[DV8]

While I agree with codestryke about finding out what works best in your situation, best practices (*reminisces about previous FK topic*) suggest that when it comes down to maintainability and versatility of your code, it's best to use one table and a properly placed indexes. Performance wise you'll probably be better off with a separate table, but code maintenance-wise, probably with one.

[133794m3r]

I'll go with multiple tables then, and I am going to use memcached once i'm able to get my hands on a server but it won't be used for many things other than holding some data like the players information for things that don't need to be read from the database and thus provide a nice staging area. Since it sounds like it'd be best to keep it separated I shall do that, since as far as maintainability goes, they'd be similar, as far as schema goes so i doubt it'd be _that_ hard to actually maintain them. And as far as figuring out which one goes into which well it'd be a simple post parameter along with some server-side checking for things such as 'announcement' messages and such.

My code itself is broken up already across multiple files at the moment which i guess makes it a 'bit harder to maintain' by the same logic. I have a file which deals solely with my SQL related things (handling sanitization of various data types such as making sure numbers are positive since no negatives are ever used, stripping all characters outside of the printable 93 'safe' characters in ascii, etc.) The folders basically state which 'group' they are in, and i've found that personally it helps me work with the code base a lot better. Since i can literally, just look at the thing and know where something is rather than attempting to scroll through things. I thought that the database would be similar, and I'm not going to be using a memory table since, you never know what /might/ be said in chat. Someone may be harassing someone else and if there's no staff member on, it's person a vs person b. No logs makes it really hard to verify such cases. That's why I even decided to make it a *real* table rather than just some memory table or something similar. Since it's all about dealing with the people who like to cause up trouble and also being able to verify things with evidence.

As far as 'consistency', I am of course talking about how the thing works. If a certain query is slow all of the time, that's ok since I know that one is always going to be really slow(taking more than 0.19s to complete is slow). Also the chat itself when they login, will do a 'get only messages since they've came online' type of thing for the channels that they are capable of seeing. Updates as they i guess should be called, are going to be done via ajax and there'll be a session variable that states the last time the update process was ran(it checks for such things ever second) and then it basically selects said data since then, and spits it out to the client in a json format and forces it to actually render it in a more meaningful way.  The whole thing at the moment builds out of javascript/ajax once you're 'in game' so to speak. The rest of the site works perfectly well without javascript but once in, it takes over does heavy lifting such as setting up things such as data values, ordering of things etc. The server just sends along a json-encoded array that was the select data from the database.

The reason for storing it in the session value was because i'm going to do a disk seek anyway, for the CSRF token that I am including in every single request from the end user that requires any sort of database interaction and as such will need to be verified so i figured i might as well store that data in it since there's a disk seek anyway.

Also to sum this up, Push based services are very interesting, but to me the idea of having to, in some sort of disagreement including harassment or scams, not having a reliable bit of information to look upon for the period of time that the event took place would make dealing with such things very complex. I have no idea if this is really the *best* way to look at this, and if anyone has any suggestions about how to be able to properly deal with such incidents and not have them devolve into the two people's "words" and "trustworthiness" i'd be really happy to hear them. The reason being that, any database query that i can avoid and there is a clearly better solution, is something that is very important to me. Also changing sql to a nosql database is not going to be something that is the "proper" answer since it's pretty clear from my various other posts and also common sense that I am using a mysql like database. Officially i'm using mariadb on my testing environment and will  be using it once i get to a virtual private server since i like the idea of hot backups, and the various other patches that improve performance the quality of logs.

[chrisjenkinson]

Performance wise you'll probably be better off with a separate table

Citation needed.

[Chris]

Separate tables will be slight faster, but still I would go for one table. I doubt the difference in speed would be so big and the maintainability and code simplicity will make up for this.

Besides, if you strive for maximum speed you probably should not read from the table in the first place but instead make a collective cache table that holds all shouts/posts that are to be displayed.

The beauty of chat is that it has no connections with other parts of the game so you can simply rewrite it completely anytime if performance require it.

[Winawer]

I think you could just use one table and partition it by channel id.

[lolninja]

Hey, I dunno how your codebase is setup, but if I were implementing a chat system using my codebase (Kohana+Doctrine+Win) I'd implement the single table system as suggested by chrisjenkinson with a channel id to segment the data.

Now because I use an ORM(Doctrine) I can just create a concrete class for each of the channels that I want within my game, each of these channel classes will extend from the ORM base class, and set their channel id, I can also preform message specific validation, say I don't want people posting links in the global chat, but amongst friends links are fine.

What this does it allow me to quickly create new messages for specific channels, for example:

<?php Global_Chat_Message::factory('Hello, world!'); ?>

and

<?php Private_Chat_Message:factory('chrisjenkinson', 'Hows it going?'); ?>

And as a subtle plus if over time I realise that my user base is using the private chat feature a lot, and its causing an adverse affect on the rest of the messaging system I can then duplicate the message table, give it a new name like 'messages_private_chat' update the models used table, within the orm and boom added performance with minimal work

[DV8]

Performance wise you'll probably be better off with a separate table

Citation needed.

Because the DB won't have to differentiate on channel ID. I can't offer you a citation because it seems self-evident to me. I have a feeling you're about to tell me why I'm wrong, though.

[133794m3r]

Hey, I dunno how your codebase is setup, but if I were implementing a chat system using my codebase (Kohana+Doctrine+Win) I'd implement the single table system as suggested by chrisjenkinson with a channel id to segment the data.

Now because I use an ORM(Doctrine) I can just create a concrete class for each of the channels that I want within my game, each of these channel classes will extend from the ORM base class, and set their channel id, I can also preform message specific validation, say I don't want people posting links in the global chat, but amongst friends links are fine.

What this does it allow me to quickly create new messages for specific channels, for example:

<?php Global_Chat_Message::factory('Hello, world!'); ?>

and

<?php Private_Chat_Message:factory('chrisjenkinson', 'Hows it going?'); ?>

And as a subtle plus if over time I realise that my user base is using the private chat feature a lot, and its causing an adverse affect on the rest of the messaging system I can then duplicate the message table, give it a new name like 'messages_private_chat' update the models used table, within the orm and boom added performance with minimal work

I mostly have it setup as such. Base PHP Functions + built in functions in 'ext', and then a pbkdf2 function that i found on the PHP page's documentation for something, i cannot remember the exact page right now but it's there. Everything else is written up by hand. The reasoning behind it is that i find OO code to look ugly and haphazardly put together. That and i dislike pointless abstractions. I use methods from jquery because that's the only way to deal with javascript to get it done.  And i also use the buillt in methods but no code i write implements new methods.  The chat function would most likely be something like, sendmessage($message,$channel);
and that to me looks cleaner than sendmessage::something($message,$channel);. The :: and the idea of using methods just makes the code feel dirtier along with the fact that it doesn't translate back into as little opcodes i've been completely against it.

And to chris, i 'could' do that but then as stated, how would i make sure to be able to effeciently handled the more annoying of people. I need a way to be able to use and just get it. And a cache table, sounds to me like a pure memory table, since otherwise, what's the point of using that instead of a table that actually stores said data?

The maintainability of the thing i doubt would be hurt that much since all tables that deal with chat have the chat_ prefix, and thus it's not terribly hard to know which are what. And their schemas are very similar. the only exception at the moment is the 'guild' chat which also has the guild's id added to the schema since it only needs to display chats from the guild that the person is in.

Schema wise, i try to make everything that deals with similar things be similar. The inventory table is setup to be just guid, player_id, inventory_slot, item_id.  And as such, i think it is maintainable. Implementing 'new' or 'more' chats is not something that i see myself doing any time soon. And if i do decide to, i have  a table which deals with the misc/staging of new chats. But i doubt the idea of adding new chat channels will be changing over time.

Since you only need normal chat, 'private' or whispers chat, guild chat, trade chat, help chat, staff chat, and also a chat which is used when it's a semi-private chat. Sort of like staff/player whispering but it's not actually part of the normal 'private' or 'whisper' chat since it's only used in specific situations. Beyond that, i see no reason to even add new ones beyond it.

It seems that to me, it's about all that will ever be needed.

[chrisjenkinson]

Performance wise you'll probably be better off with a separate table

Citation needed.

Because the DB won't have to differentiate on channel ID. I can't offer you a citation because it seems self-evident to me. I have a feeling you're about to tell me why I'm wrong, though.

There's an opportunity cost to opening the various files needed to access another table, the index, etc..

However I think a major point is that the time spent reorganising code to change it from one type to another far outweighs the time & resources saved by the server.

[Chris]

And to chris, i 'could' do that but then as stated, how would i make sure to be able to effeciently handled the more annoying of people. I need a way to be able to use and just get it. And a cache table, sounds to me like a pure memory table, since otherwise, what's the point of using that instead of a table that actually stores said data?

Even using the same storage system there is a read benefit. You need to read 1 row to get 20 posts that otherwise would require getting 20 rows (of course this would not be 20 times faster, since reading consecutive rows, especially under primitive storage engines like MyISAM is quite fast), then you need to sort them via certain criteria. With cache you have this all done by reading 1 row which contains preformatted HTML of the most recent 20 posts and you just echo it. Take a note that this work only under assumption that there are significantly more reads (people watching chat) than writes (people replying).

There's an opportunity cost to opening the various files needed to access another table, the index, etc..

Take a note that in chat you have only 1 channel open at a time. So the need to access multiple tables will never emerge.

[lolninja]

I mostly have it setup as such. Base PHP Functions + built in functions in 'ext', and then a pbkdf2 function that i found on the PHP page's documentation for something, i cannot remember the exact page right now but it's there. Everything else is written up by hand. The reasoning behind it is that i find OO code to look ugly and haphazardly put together. That and i dislike pointless abstractions. I use methods from jquery because that's the only way to deal with javascript to get it done.  And i also use the buillt in methods but no code i write implements new methods.  The chat function would most likely be something like, sendmessage($message,$channel);
and that to me looks cleaner than sendmessage::something($message,$channel);. The :: and the idea of using methods just makes the code feel dirtier along with the fact that it doesn't translate back into as little opcodes i've been completely against it.

Thats cool, not everyone has the same taste in everything, the thing I really like about OOP is how it lets you do the same thing in multitude of different ways. From an OOP developers perspective simply calling a sendmessage('message', 'channel'); feels wrong, because you then have to remember which channel is what. And for me personally I'd be constantly putting the wrong channel id into the overly generic message sender.
 
Whereas with a nice self documenting static function call, it either works because you remembered the name correctly, or gets picked up as an error when your testing it. With your broad parameter list approach, I find that errors often slips though the gaps, more so because I never worked out how to unit test functional code :S

One last point concerning...

Take a note that in chat you have only 1 channel open at a time. So the need to access multiple tables will never emerge.

I think this depends on the way the UI is implemented, if for example you enhance your interface using javascript, and decide to implement tabbed chat channels then you may well want to be able to access multiple channels at once. In this kind of situation OOP is imho king, as you could build the system so that your call looks like.

Code: [Select]

Overly_Awesome_Chat_Manager::create()
    ->getChannel('global')
    ->getChannel('private')
    ->getChannel('region-my-awesome-farm')
    ->execute();

With an implementation like this you'll be getting 3 channels worth of content with one database select, even if the content for each channel is separated across multiple tables.

And to summarise, with any problem domain there are infinite solutions, but unlike Chimps with typewriters most of the solutions can be made fit for purpose, the end goal though has to be getting it working, so make code happen

[Chris]

I think this depends on the way the UI is implemented

Sigh... I knew, just knew someone would say it Yes, you can find obstacles if you look hard, you can find ineffective and difficulty situations and you can step into them with open arms and with song on your mouth. Maybe I'm weird but I always try to stick to the easy, simple, reliable and fast route

Besides, your OOP heavy UI still sux because it does not send SMS notification when someone write your name

[lolninja]

Besides, your OOP heavy UI still sux because it does not send SMS notification when someone write your name

Nothing I write 'sux', and SMS notification is easily added to my 'OOP heavy UI'.

http://www.mediaburst.co.uk/api/

[133794m3r]

[snipped to terseness]

Thats cool, not everyone has the same taste in everything, the thing I really like about OOP is how it lets you do the same thing in multitude of different ways. From an OOP developers perspective simply calling a sendmessage('message', 'channel'); feels wrong, because you then have to remember which channel is what. And for me personally I'd be constantly putting the wrong channel id into the overly generic message sender.
 
Whereas with a nice self documenting static function call, it either works because you remembered the name correctly, or gets picked up as an error when your testing it. With your broad parameter list approach, I find that errors often slips though the gaps, more so because I never worked out how to unit test functional code :S

The actual 'channel' that is currently selected is done via the user sending it with the channel that is selected in the UI. Currently there is one 'chat' window with an option to click on little 'tab' like buttons and then switch to only chat channel+global announcements/whispers(or private messages) so that bit of data is just coming up stream automatically. Or they send off a '/' commands. like /g for the 'guild' chat. And as such it's converted to its numeric value once up stream it verifies that such a thing is even possible then inputs it.

And as far as remembering which is what, there's only what? 255 possible chat channels? Not too many(still a lot of possibilities) but i have a file setting in my /doc folder that states what every channel is incase i forget. Later on, though, it'll probably be broken up into various little functions since a function should do just one thing, but for now there's that bigger function that sees if the other things can even be called.

The last thing that i didn't see, i don't know how i didn't, but it wasn't until you(lolninja) brought it up that i noticed it. I will be having multiple channels open at once. Currently when a player has the default settings on there is the following channels 'open'; normal, world, whisper. Then conditionally ie if they're in a guild it could also add 'guild', and if they're in a city it'd be the 'trade' chat as i'm calling it which is a city wide chat channel dedicated to, well you guessed it bartering related things.

So there is multiple ones, but there can only be one message sent per player to each table at a time. Along with a minimum 1s global cooldown on everything i doubt that there will be reasons to send multiple messages to each one.

The OO way of programming was pretty neat when i first heard about it, i was like, oh this is an interesting way of doing things. But then I realized that it was another abstraction layer and slowly but surely my focus on performance on the resulting application took over and i've never looked back. I dislike extra abstractions that i need to. I'm all for the abstractions that C provided since that was well amazing once i got into that, but going out further just feels weird and hte idea of it sits with me wrong. That and the knowledge that objects have to take up more memory than a simple string for example and will take up those precious op codes and bytes of ram, makes me cringe when i think about implementing them.

My programming languages basically went as such. BASIC -> Assembly -> C -> Java/C#/F#/Ruby/Perl/TCL/Python/(if you count bash scripting as something)BASH -> PHP/Javascript/SQL.

the middle part there, was when i was bored with C and wanted to see how other people were doing things to see if i would like their way of programming better than what i was used to( at that point it was mostly C and assembly knowledge was getting rusty). All of them had some interesting bits but overall weren't enough to stick with me. Then when i decided that i wanted to try to make a web based game i looked at php saw that it was rather procedural wasn't as brutal as perl, and jumped into it. Javascript is still weird, and i will never understand what they were thinking when they wrote said langauge.

Now, then, and back off of that ramblings, and back onto the topic at hand. Since it seems as though my idea to keep them somewhat separated was the best way, I'll forge ahead with the idea that, my database schemas for other similar situations was done properly.

Thanks to everyone, who took time, to post in this thread and provide their opinions about the topic herein.

Edit: Wow, that was rather fast lolninja, i wouldn't have expected you to come up with an api to send out text messages via OOP PHP so quickly. It must be some sort of black magic or some similar mysterious force that you have tapped into.

[JGadrow]

The OO way of programming was pretty neat when i first heard about it, i was like, oh this is an interesting way of doing things. But then I realized that it was another abstraction layer and slowly but surely my focus on performance on the resulting application took over and i've never looked back.

I am a supporter of OOP. However, I will note that if your goal is to save a few milliseconds, yes, you should go with procedural programming. But, seriously, the goal of OOP is to make code that is easy to use! The machine's time is cheap... my clients will tell you that my time is not! OOP allows you, the developer, to spend less of your time programming. Sure, the CPU spends an extra bit of time with the abstractions. But does the CPU have a family and friends to spend time with? Does it need sleep? Restroom breaks? A dog that needs walking before it decides the carpet is an acceptable toilet? I think not. Time is a person's most valuable resource and OOP helps us have more of it.

I dislike extra abstractions that i need to. I'm all for the abstractions that C provided since that was well amazing once i got into that, but going out further just feels weird and hte idea of it sits with me wrong.

Well there's your problem. C was notoriously unfriendly for OOP developers. That's why C++ was created.

That and the knowledge that objects have to take up more memory than a simple string for example and will take up those precious op codes and bytes of ram, makes me cringe when i think about implementing them.

They don't take up more memory! They take up the amount of memory equal to the amount necessary for their properties. The OOP just places related properties into a convenient wrapper for the developer to use!

If you were to write:

Code: (c) [Select]

int x = 4;
int y = 7;
You have 2 integers which take 4 bytes in memory (maybe more now, been a while).

If you write:

Code: (c++) [Select]

class Coordinate {
    public:
        Coordinate(x,y)
            : _x (x), _y (y) {}
    private:
        const int _x;
        const int _y;
}

Coordinate location = new Coordinate(4,7);
You're still only using 8 bytes of memory (4 + 4) which is the same as you were using anyways! Now, it's just been conveniently wrapped for you! Also, you can write functions to manipulate / use your coordinates in ways that you would need to write functions for (and pollute the global namespace with said functions) quickly and easily! Oh, and you can also pass both values as a single parameter to any function, method, etc. when necessary!

the benefit of OOP though is what if, down the road, you decide: "Guys, we're switching to a 3d layout. We need to add z to coordinate locations." Well, you're kind of screwed no matter your situation in this case... but if you've gone the OOP route, you simply add the relavant code in your class declaration (new private member, add initialization to that private member) and go add the new z values to your code. In the procedural approach, you'd have to type out the extra "int z =" for each spot it was added. You can see that the OOP approach is already saving you lots of keystrokes... keystrokes equal your time. Save those keystrokes a couple thousand times and you've probably saved hours of your life from being wasted.

I dunno about you, but there's already not enough hours in a day to suit me! Anything that helps me save time is a benefit!

Anyways, to the original point... I would actually choose the single-table approach and then branch out to multiple tables to store channel-specific data. You could always choose to create views based on that primary table for each channel at a later point if necessary.

It's in my nature to hate unnecessary duplication. Duplication = bloat. I tend to look at database tables as something akin to objects (structs really as there's no methods to tables, just data) in a developing sense. The base table would store the generalized data. Additional tables would be created to store specialized data. But then, I think lots of things in games are just specialized uses of the messaging system. A "battle report" is a specialized type of message sent to the players involved in the battle and containing additional fields (like, opponent, location, etc.) and a different presentational logic. *shrug*

Edit: Wow, that was rather fast lolninja, i wouldn't have expected you to come up with an api to send out text messages via OOP PHP so quickly. It must be some sort of black magic or some similar mysterious force that you have tapped into.

Told ya... the goal of OOP is to save you, the developer, time! It's no surprise to me that lolninja could add whatever was necessary to his chat much faster than it could be done procedurally.

[133794m3r]

To make this post simpler to post. I was speaking about PHP implementation of objects. Their way of it, supposedly uses more memory. I know that in compiled languages the memory use is less and thus it's better for the end developers.

c++ is an interesting language, and my first interactions with it was when i looked at the original doom source code. It looked pretty interesting but i still didn't really care for it a ton.

As far as the table approaches, that's one thing that i attempt to do with everything. No repeats, but i also want to make sure that it's faster. The few milliseconds are important for most things that i am doing but some it's not really(for example, as i said i'm using jquery) since javascript is an odd enough language as is.

As far as the example of adding the z plane, i don't know how it'd be terribly different to do something such as a function which handles all movements. And then i'd just add that function that moves the players around. Since there'd need to be a collision detection anyway. The function is going to have to be there anyway in the future.

The actual design of the thing is to be as modular as possible. Each thing is it's own little 'system' and they of course have parts that then link into each other and have some code that basically uses the various modules to do its things. So I doubt it's going to be that much harder to work with/update than an OO program.

The very last thing, is that it is a lot easier for OO programmers to find code online since almost everyone is using it(for rather obvious reasons) so it's hard to find code that is purely procedural or at the very least isn't overly OO. I'm not using any framework because first off, I'm more interested in learning PHP rather than some framework's way of working in php. Secondly, because they're all overly OO and their security practices are laughable at best.

My 'most important' things are performance stability and security, then comes usability for end users since if any of the first three is not possible then i doubt anyone would even want to use the thing. After that it's all about modularity, and finally ease of use on the other coders.

The actual tables themselves are mostly interlinked via foreign keys so that tables don't have pointless bits of data in them. I guess i'll go back to the original table idea for chat then. The inventory system is currently one huge inventory table, and then a table for guild 'banks' which handles the additional 'permission' data on it.

[codestryke]

They don't take up more memory! They take up the amount of memory equal to the amount necessary for their properties. The OOP just places related properties into a convenient wrapper for the developer to use!

Code: [Select]

class Coordinate {
  private $_x;
  private $_y;
  
  function Coordinate($x,$y) {
   $this->_x = $x;
   $this->_y = $y;
  }
}
$location = new Coordinate(4,7);
echo memory_get_usage() . "\n";
63,688

Code: [Select]

$coordinate = array(4, 7);
echo memory_get_usage() . "\n";
60,696

Code: [Select]

$x = 4;
$y = 7;
echo memory_get_usage() . "\n";
60,440


Yes objects do take up more memory. Just as an array will take more memory then declaring separate variables just as a struct will take less then an object but more then the raw variables. What you get for allocating more memory is better defined access to said variables though the object. Convenience costs, not only in speed, but memory as well, wrappers are NOT free

[Nox]

The example is flawed, imho like 95% of the extra memory consumption is spent on class, not object, try instantiating another one
(in my tests in past it was like 99% class)

[lolninja]

wrappers are NOT free

From memory, its been a while since I had to study how Apache and PHP work at a C level, but yes you are correct in stating that the wrappers have an associated cost, but not directly in the way that I *think* you mean, if I am wrong I apologise.

Basically the added memory comes from having to parse more code, as your paring 10 lines vs 2-3 in the other examples. Once parsed the class's blue print is stored in memory, then any instances of that class contain a pointer back to that blue print, and the unique instance variables themselves.

So technically when JGadrow said they use the same amount of memory he was slightly wrong but I assume this was to avoid unnecessary confusion. The omitted detail is not mentioning the need for an in memory blue print, and a pointer from the instance to the blue print, BUT pointers are tiny memory usage wise, and you can get optcode caches that store the blue prints in memory, so in a correctly set-up production environment an OOP based system will use a tiny tiny amount of additional memory.

Now while being a fan of OOP based system, I do recognise the need for procedural programming, but the only time I would personally implement anything in this style, is when a page is meant to be hit by extraordinarily high volumes of traffic. And in my experience sites that get hit this hard tend to be offering free content, and your trying to do something on the cheap, normally for a client who wants the earth for a penny :S

But with a game, your going to be generating revenue, which means you can scale to a multi-box solution long before the additional memory over-heads become an issue.

At this point I may seem like I'm being overly negative towards procedural implementations, but that's not my goal, I'm just trying to make it clear that OOP implementations are quickly becoming as efficient as procedural, and with further revisions to the PHP engine, there may well be a point where writing code procedurally is in fact slower than the officially supported method that is OOP.

And like JGadrow said, OOP is quicker to write, meaning more time with the family and down the pub

[JGadrow]

lol I probably should have mentioned I meant there's no extra memory consumption in C++... it's a compiled language so it all boils down to machine-level instructions in the end. I had thought the OP 133794m3r was claiming that in the compiled language it utilized more memory (as he indicated that was where his forays into OOP began). I thought that point was self-evident by the fact that I gave examples in c and c++... but that's what I get for assuming! lol

Anyways...

As far as the example of adding the z plane, i don't know how it'd be terribly different to do something such as a function which handles all movements. And then i'd just add that function that moves the players around. Since there'd need to be a collision detection anyway. The function is going to have to be there anyway in the future.

The difference is now you have to pass in coordinates. With the class solution, you have some built-in validation. Also, you can pass all relevant variables wherever they're necessary as a single parameter. Or store an array of them conveniently.

The very last thing, is that it is a lot easier for OO programmers to find code online since almost everyone is using it(for rather obvious reasons) so it's hard to find code that is purely procedural or at the very least isn't overly OO.

This is completely false. Sure, it's easy to find a lot of poorly written OO code. Honestly, most OOP developers that I've seen don't really get the OO concept. The example I gave above was purely for the sake of simplicity. Honestly, I would probably never create something that simple as an object unless I had a very good reason for doing so. Objects are supposed to have methods meaning they're not just convenient data wrappers (though that is very handy) it's a way for you to create functions meant to manipulate the data stored therein in a meaningful manner.

For example, if PHP was a language where the integral types were actually objects (as in some other languages), we'd be able to do things like:

Code: (imaginary) [Select]

$var = 'my string';
$words = $var->explode(' ');
In such a world, it would be known that we're operating on a string (and which string) meaning there's no need to pass it in as a parameter, validate that the parameter is, in fact, a string, throw an error, etc..

I'm not using any framework because first off, I'm more interested in learning PHP rather than some framework's way of working in php. Secondly, because they're all overly OO and their security practices are laughable at best.

Good for you! I cannot tell you how many times I heard the phrase, "Why reinvent the wheel?" when I started picking up PHP... Why? So I can understand why the wheel is useful in the first place. On top of that, maybe I want to improve the wheel and make it a bit more modern! Cars don't use stone tires after all. As far as security goes... insecurity is rampant. I'm lucky that I have someone very close to me who does nothing but secure systems for a very large corporate entity (meaning he's seen just about every hacking attempt, stupid user story, virus that's active out there) to help keep me on the straight and narrow when it comes to security. Notice that almost every time I post on here I use the world 'validate' about a billion times? Yeah... that's because it's second-nature to me. lol

My 'most important' things are performance stability and security, then comes usability for end users since if any of the first three is not possible then i doubt anyone would even want to use the thing. After that it's all about modularity, and finally ease of use on the other coders.

Wow... your priorities are in reverse order from my own. To paraphrase a popular quote: "If you can quickly change it, they will come." I'll use an example from PC gaming... WoW. It didn't start with a zillion players. It started out and was quickly overwhelmed with the players that did initially purchase. Servers went down, code broke, it was chaos! But they were able to quickly adapt! Now, there's not a game on the planet that has ever been as popular as WoW... not even D&D! Part of that popularity is because they make frequent changes to the game in response to bugs, balance issues, releasing new content, etc..