forums.smartfoxserver.com

hi bax, still zoomandenhance here (other login)

This might not be the best place to discuss, but I'm wondering about OS best-practices / architecture in general (and in relation to a Facebook game).

To frame some questions I'll outline my potential architecture below.

I'm imagining that game users will create an account for themselves and have a room created with map associated that is derived from one of a few templates (as you describe in documentation), for example, beach template, park template, etc.

The user will have an account created in mySQL where their map structure will be stored (along with other status / game progress information).

Now - I'm hypothesising that the template maps and inventories / libraries could be stored together in mySQL table and referenced there where the unique key was the name typically associated with an OS project, i.e. osExample1 (from the official examples). The unique key / project name would be prepended to the _os_mapId value when assigning maps to users when first created. I'm imagining that storing the 'templates' in this way would be neat but am not sure whether the file-system approach offers more efficiency / less overhead than queries.

In my extended OS Java extension I would override the non-final methods dealing with map / inventory / library to utilise mySQL rather than file system.

To this point my assumption is that the intent of the inventory and library files is that they're predominantly static, i.e. the user maintains their map data against their unique 'account' but refers to the template's inventory and library (templates table). Is that the case or is there some potential use-case / approach where each user might require their own library and inventory?

As the user 'purchases' inventory items references are added to their user account (mySQL) so as the master inventory can be filtered via the getInventoryItemsList method. Purchased items would be stored as a list of id's (matching inventory item id's assigned in OS editor) in user's account (mySQL).

There seems to be quite a lot of documentation and discussions about SF best-practices and architecture but not so much for OS so I'm hoping a few people might weigh in with their perspective / ideas.

Thanks in advance if you do

(post split, to make it a separate discussion)

I'm imagining that storing the 'templates' in this way would be neat but am not sure whether the file-system approach offers more efficiency / less overhead than queries.

Actually we have no evidences that storing maps to a database is a better solution than using the filesystem as by default. The disadvantages of using a database are clear: you have to override all those methods and write the logic to read/write, etc. But what are the advantages?
As you have unique usernames, you just have to duplicate the template map giving it a per-user unique id, for example osExample1#RanchInside_baxUser, and keep all the maps in the filesystem (of course with a good backup system).

To this point my assumption is that the intent of the inventory and library files is that they're predominantly static, i.e. the user maintains their map data against their unique 'account' but refers to the template's inventory and library (templates table). Is that the case or is there some potential use-case / approach where each user might require their own library and inventory?

Probably there is some misunderstanding here. The 'template' approach we describe in the documentation is referred to maps only. The assets library and the inventory are global to all maps, and absolutely not referred to users. When a map is loaded by the extension, it only contains the tiles IDs. The tiles and skins definitions are contained in the library file, and are merged with the map data before sending everything to the client (the same with the inventory, whose items refer to tiles from the library).
So the approach is: in the Editor you export the library (containing the definitions of all skins/tiles/backgrounds available for maps and inventory belonging to the same project), the template map (even more than one if you need) that you will duplicate for each user, and the inventory containing items to customize the maps.

One more word on templates duplication: of course this is the suggested approach for user-specific maps, for example the user apartment. You don't have to make a copy of all the available maps for each user. common places (the beach, the park) which are shared among all the users don't need a per-user copy. Otherwise you will end up with a virtual world in which each user navigates his own maps, without encountering other users. Sorry if this was already clear, but we just wanted to make sure.

As the user 'purchases' inventory items references are added to their user account (mySQL) so as the master inventory can be filtered via the getInventoryItemsList method. Purchased items would be stored as a list of id's (matching inventory item id's assigned in OS editor) in user's account (mySQL).

Yes, this is the right approach.

There seems to be quite a lot of documentation and discussions about SF best-practices and architecture but not so much for OS so I'm hoping a few people might weigh in with their perspective / ideas.

OpenSpace is a much younger product, and of course also less used with respect to SmartFoxServer. With the help of the community posting messages like this, we will be able to expand the best practices discussions. Thank you.

Hey Bax,

Thanks for responding so quickly and opening the discussion from an official perspective Since purchasing our SmartFoxServer and OpenSpace licenses we've been very happy with the response times to questions on the forum. I'm a believer in the views expressed here. I'm sure you've read it since you include the greensock tweening code in OS (although there are much newer versions available ). My experience with some OS isometric engines has been positive, FFilmation to be exact, but I believe the level of support, robust product and multiuser integration offered here is far preferable.

I'm hoping that what's discussed here might be of use to the community at large and to those who are considering using SmartFoxServer with OpenSpace.

So...

Actually we have no evidences that storing maps to a database is a better solution than using the filesystem as by default. The disadvantages of using a database are clear: you have to override all those methods and write the logic to read/write, etc. But what are the advantages?

I note in your documentation for the buddy list 2.0 extension you comment

Instead, it uses an internal high-performance database which provides better speed and security

Does this have any relevance to the discussion re: database vs. filesystem? What security concerns can you visualise and are they applicable just to the buddy list / extensions?

One more word on templates duplication: of course this is the suggested approach for user-specific maps, for example the user apartment. You don't have to make a copy of all the available maps for each user. common places (the beach, the park) which are shared among all the users don't need a per-user copy. Otherwise you will end up with a virtual world in which each user navigates his own maps, without encountering other users. Sorry if this was already clear, but we just wanted to make sure.

As I mentioned in my previous post, my use-case for SFS and OS is a Facebook game in the mould of FarmTown. Considering this, each user will have and maintain their own map / environment which may then be visited by their Facebook friends, if they have registered for the game. There will be a cap on how many friends can visit another user's map at any one time. In addition, user's maps will be populated with some NPC's and some pseudo-NPC's ('characters as skins' / static character artwork attached to tiles). Within this model there may be some common maps that can be entered from within each individual's map. Conceptually, this might be something like a specific building that appears in each user's map, i.e. Cafe, that leads to the common map where more users are likely to congregate (but still only those users linked to Facebook account).

Probably there is some misunderstanding here. The 'template' approach we describe in the documentation is referred to maps only. The assets library and the inventory are global to all maps, and absolutely not referred to users.

In light of this I believe the best option, for us, is to store user maps against their account in the database and leave the template map and inventory / library on the file system. I'd prefer not to have to extend any more of the OS extension methods than those related to the map.

On that point, would the correct procedure in extending isMapUpToDate be to store the last modification date in the users account in database (to convert to milliseconds when required) and then compare against the argument? Is the lastUpdate value being passed to that method being stored elsewhere in the SFS embedded database for caching?

Moving on to another structural concept - to integrate with Facebook we're using the Facebook ActionScript 3.0 API which will allow us to capture data about when our Facebook friends log on, update their profile, etc. I'm now wondering whether it would be a good idea to use the SFS buddy list 2.0 to store that friend status information in a manner that provides tighter integration with SFS and OS. My thinking is that by using the buddy list I can merge user status and game progress data into one place. Does this sound like an idea that reflects the intent of the buddy list or is it more focused on chat / IM implementations?

Thanks again for all your input!