Printable View
I intend to have the game I'm developing sponsored, which I've never done, and I'm loading the data for each level from XML... how does this work with sponsors/portals since they usually just want a single swf? Do I need to store the XML on my own server and have the game load it from there? What if I don't have hosting, or hosting that can't handle a lot of bandwidth?
contact your client and discuss it with them,- maybe they are so reasonable and offer you xtra upload for the xml.
Imo. its a outdated way of thinking that everything fits into 1 swf file- esspecially considering working with AS3 where using xternal data is often a must.
I agree that it is outdated, unfortunately most game 'sponsors' still make it a rule that the game must be packaged in one SWF - otherwise it is much more difficult for the game to spread and they dont get as much exposure / money.
Of course if you go for an exclusive license for one website this shouldn't be much of a problem.
The obvious alternative is to embed the xml files or parsed arrays in the SWF.
Thanks for the info guys
@renderhjs - I agree it's ridiculous... I wish we could load whatever we want externally, bitmaps and everything. Unfortunately I don't have a client since the game is unfinished and hasn't been shown to any potential sponsors or anything. I'm just realizing it's probably going to be a problem and want to know if I need to change the way I'm doing map editing/loading (which I really don't want to do).
@random10122 - An exclusive license is possible, if I can get one... I don't really want to rely on it if I can help it though. How can I embed XML files in my SWF? I looked around on google but could only find information for doing this in Flex, and I'm working in CS3 (suppose I should have marked the thread as [CS3]). I guess I could have the level editor spit out the XML and copy paste that into flash and parse it... but that seems silly
Are sponsors showing any signs of changing their antiquated policy?
Why its no good for players of a game and also not for portals when big games are contained in one file:
I totally agree its no good that many portals only accept one file games. This may seem like more convenient to them (though even just the point of embedding the game isn´t any more convenient of course, there´s not much difference between copying a bunch of files into a folder and copying just one file into a folder) but it of course has quite some downsides for them just as for the visitors of their page when bigger games are contained in one file instead of being split up.
When you have a bigger game seperated into main file and seperate assets loaded in as needed later on this can lead to way shorter initial load time for the player of the game and for the portal hosting the game it can mean way less server bandwidth usage for same amount of players (as only the parts of the game are loaded that are actually played/unlocked by the player not all assets as in when loading a big whopper file in one go for every player).
I hope the portals dealing with spreaded games realize this with time and then accept multi file games more and more.
Test Case
I have recently tried several possible workarounds for the problem already mentioned, here´s my experiences with em:
Since i have a pretty high bandwidth usage cap on my own servers i wanted to see it with one game that is spreaded around on many sites how much traffic it would cause when i host the later level assets on my site and the game portals only host the main game file on their site (and the rest of the assets is loaded from my servers when needed).
I had made it so the main file uses mochiads versioning system so that i could just deploy a new version later on which would not load any assets from my servers and then that new version gets loaded on all the sites the game runs on, so i could basically stop this test pretty close to when i wanted to.
If you don´t do something like that where you can "swap out" the main game swf on all the sites it runs on easily i suggest NOT TRYING A TEST LIKE THIS, just as much as i can´t suggest trying it if you have to pay high for any high traffic on your own servers.
As example for a game where the main swf was around 1mb and the assets it
loaded in from my server were in total around 4 mb this caused me around 230 gigs of traffic in less than one month.
For many hosting plans this could lead to massive additional costs.
Also yeah, even if it doesnt cost you additional money fror your hosting i still wouldn´t suggest it as it might be that even if your traffic volume isn´t used up such a cross loading of external assets from different servers, even ones in different countries could still quite easily lead to a not so nice experience for players of your game.
For many reasons it can happen that the main game file on portal x gets loaded and then assets from your server don´t get loaded as they should, the result is that for a player of the game your game just looks buggy and hes not into playing it anymore, whereas if all assets of a game are hosted on the same server you can be pretty sure that either the game page doesn´t load if the server has a problem or if it can load and display the main game file then that´s also the case for the additional assets hosted on the same server so then your game works fine.
Workarounds
In case you wonder what i did then with that game, well, its the other thing talked about here, that is incorportaitng all seperate assets into the main game file and then deploying that to the sites via mochi versioning.
Now the good side is that the bandwidth usage on my servers went down of course, though it is still no ideal solution for the players of the game of course.
They now have a way longer intial load time when playing the game and then also for each player the whole big file with all assets integrated is loaded, not just the portion he plays (which for people only trying a game shortly may have been a much smaller chunk).
It was also a lot of overhead to integrate all the external assets into the main game file and now that overhead is also not done with a one time overhead, i have to repeat it of course everytime i want to update any of the assets as they are now part of the main swf, so each time i want to change one asset i have to compile the main swf again and deploy that whole thing again, all a big waste of time and ressources.
Regarding how to integrate assets into the main game file, there are several ways:
If its an AS3 game you can use an embed command to have assets like images etc embedded into the main swf during compilation. For some file types where you can´t let them be compiled into the swf automatically you could also store their bytearray or readable form data into a string variable etc.
Now regarding the actual loading handling for a bigger file in one part:
There´s of course the problem that when you export all elements with class/linkage in frame 1 of your swf then your game/preloader doesn´t even show up until all those assets are loaded. This can look to players as if your game doesn´t load or crashed.
If you do the workaround of not exporting such assets in frame 1 but instead have a place in your fla/swf where you have all those assets integrated into a mc etc so you can show your preloader and preload that thing then your preloader shows up before those assets are loaded but still the user would have to wait until all are loaded before he can even start to play the game.
So what you can do then is for example you have a fla with an mc where in each frame you have those assets placed that are required in a certain level/section of a game (basically each frame features assets you´d do in one load call back when your game was sperated into several asset files).
Then you can always show a preloader that checks if that frame of that assets containing mc(s) is loaded.
This is quite a bunch of extera work of course.
Then with embedding txt/xml files in the form of having them stored in a variable as string you also have to consider various limitations of flash, it can´t handle more than a certain amount of code per frame and per class for example, so if you have big level xmls etc and want to handle them as string variable and just put that variable into a frame in your fla or into a class file you might run into some problems there.
Bottom Line
Again, all these things for including seperate assets into the main game swf cause a lot of overhead for developers and as i said before for bigger games it would make sense for game players (shorter initial load times) just as much as for the portals hosting the games (less bandwidth usage per player) to allow seperate asset files being loaded in later on, i hope that the awareness on that topic raises.
Addition to this:
I also hope that sites like flash game license get active on this and allow uploading multi file games, too to endorse a propper solution.
Meanwhile i´d suggest you show the game to possible sponsors on your page and link to a zip containing all files for those who want to look at it.
he he a very passionate topic of yours ;)
I guess that many of the hosters are not mature enough- have not yet thought outside the box yet- dictate rather than listen.
Eventually soon the first will rethink their direction and make their place a better home for professional developers - and if it succeeds (because of better, bigger, complex content?) others may copy like they used to.
I´m passionate about many things, when its about flash related stuff i just have already written novel sized posts on many topics so its rarer these days that one comes up about which i haven´t written a lot yet and feel the need to :D
Regarding this topic i´m especially into it right now because its not been long ago since i went through all that i wrote about in my previous post,
in the end i spent around 3 days integrating all the many assets into the main game file in a sensmaking way and still feel like i did a disservice to the players of the game and the portals hosting the game by doing that, so yeah,it would be the best for all sides if the sites just support multi file hosting.
And yeah, i too hope that one or some sites start with a good way (and sure the others would copy it with time then but still those doing it first would have an advantage on some ends for a while).
Wow, thanks tomsamson. Your test case was particularly interesting... that's way more bandwidth than I expected/hoped, so I won't be going that route. I guess for now I'll plan on copy-pasting the code from the xml file into an xml object in a .as after I'm done building all the levels. The levels themselves won't be huge so hopefully I won't run into the limit you spoke of. I was already doing the trick of putting everything on frame 2 and preloading on frame 1 since I knew I couldn't load any bitmaps/sounds externally so at least I don't have to make any changes there.
Thanks again! Hopefully the people on FGL having similar problems will find this thread useful... and then start complaining about it to sponsors. :)
:) Well, ideally portals seeing this will think about all the traffic costs they could save, beeing able to serve the same amount of players with way lower costs and then improve things without game developers having to moan a lot :)
I´m glad if the post helps and also if you have a solution that´s fine for your needs. Its alway a decission to make from case to case, if you have lots of media assets you´d have to export in the swf or big data files then having seperate assets would make more sense, if its only few/small in filesize assets and its feasable to export it in the swf, then yeah, that´s ok,too of course.
Now im confused
If you want mochiads in your game, what you will have is an swf that will load everything from mochi server, isnt it?So,cant that iLoadEverything.swf be considered the only and only one swf that you give to those portals?
There are several options with mochi so that´s maybe why the confusion.
You can for example just have mochiads in your game for example, then in the most basic case mochi wouldn´t host any files, you´d spread the main swf and any asset files and they would then be hosted on the server of the game portal that grabs that game.
Then you can also have mochiads versioning for your main game file, in that case the mochi code in your game checks if the site hosting the swf has the latest version, if not it loads the latest version swf from the mochi server.
I noticed that that works well if the user has set the browser cache option to check for a new file each time and not so good when the user has default cache settings in firefox for example (then usually still the old file gets loaded).
Anyway, then next up you could use mochi hosting based distribution for your game so then the files get loaded from the mochi server.
The portal could still host the main file and then seperate asset files could be loaded from mochi servers for example.
That´s an option though you have to consider more things in that case, like for example cross server loading related security sandbox restrictions, also that a game could look buggy if the main file on the portal site can be loaded but then for whatever reason the mochi server is inaccessible/files there can´t be loaded, then it also gets more complicated if you use versioning for the main file because in the mochi system you can only have versioning for the one main file and not the assets pack so that could get convoluted if you don´t watch out. Also the uploading of games made up of multiple assets is a bit cumbersome, you can either upload a single swf or a zip of files, in case of a zip of files it only works if there´s an swf among the files in the zip and then it also automatically sets one of the swfs in the zip as main file automatically so you might want to upload a zip of assets (in case you have several swfs in your project) and then afterwards the main swf
to have that still be seen as your main swf.
So as summary: Yeah, possible, but you havve to consider some more things to pull it off nicely.
I´m currently testing this way with one game so if anything interesting comes up regarding that i´ll post again about it.