Game Development Buzz

Every flash developer who have worked with loading external data would have had his fight with crossdomain polices and flashplayer security issues. We may we trying to load some images or XML data into our flash movie and it will be working just fine in the local machine. When you deploy the flash app online it wont load any data and yet wont display any errors too. This may be a headache for first tiers who are yet to know about flashplayer security issues and its restriction to load data only from explicitly allowed domains.

If the loaded data resides with the same domain you may end up with out facing this particular trouble, but things become real tricky when you try loading data from different domains. With Flash player 6 a security sandbox implemented a restriction : a movie sitting on one domain would be prevented from loading data from another domain. In Flash Player 6, sub domains of the same parent domain could access each other's data this is not the case anymore starting with Flash player 7, domains must be identical for data to be read.

So in order to enable such loading we need to have a 'crossdomain.xml' file in the data hosting domain root which enables access to the domain where the swf is hosted. Crossdomain.xml looks like this.
By default the flashplayer looks for the crossdomain.xml within the data domain root. If it finds access enabled for its domain then data is loaded. With the addition of System.security.loadPolicyFile, Flash Player 7.0.19.0 can load policy files from arbitrary locations, as shown in the following example:

System.security.loadPolicyFile("http://mydomain.com/sub/dir/myPolicyFile.xml");

This will solve the problem associated with loading xml files, but loading images and swfs is a different story altogether. It gets a bit complicated with the use of LoaderContext and Security.allowDomain. Here is the Adobe post on loading swfs and images from another domain.


var context:LoaderContext = new LoaderContext();
context.checkPolicyFile = true;
var urlReq:URLRequest = new URLRequest("http://www.[external domain].com/photo11.jpg");
var ldr:Loader = new Loader();
ldr.load(urlReq, context);


So ultimately the understanding is that we need to allow domain access and also use a loaderContext for loading images.

Google lets you know what a browser is through this new site and the video.

I received the alpha invite for source binder visual flash development tool. I am really excited about this. But here is a video which demonstrates the simple power of the tool.

Hello World tutorial - Sourcebinder from Viktor Kelemen on Vimeo.

PBE uses a really different architecture for building their framework. This video helps us get started.

Image via Wikipedia

Some months back i was trying to work on the flex game engine. Had released a version and developed some games based on it. There were also plans to further extend it. But now we have open source heavy weight flex/flash engines likes the Push Button Engine from the Torque team. So any flex engine now becomes obsolete in view of PBE which is having some real work being put into its development. Each month there are revisions released for the game and its maturing day by day. So story of my flex engine ends here.
Now it is time to update our flash game engine. The current engine is a simple port of the original AS2 engine that we had. It was developed when we started learning AS3 and it now seems like a toy car of sorts. So the plan is to redo everything from scratch which helps development pipeline at Csharks. This post is intended to keep track of features that may be needed to be developed, so it will help those who are developing similar engines right now.

So broadly speaking the engine for Csharks needs to do 2 different things.1) It should help development of client works, reduce time, increase efficiency and make life easier for artists and programmers working together on the project.2) It should be extended to create specific Csharks game engine which we will be using for developing all our in house games and games for our supported portals. So the original engine is to be a kind of framework and the final in house engine will be a customisation of that framework specifically for set of features.

Lets try listing down the features for the framework. (this will be a work in progress for some time to come until i finalise it and start development. I will keep updating the post and putting comments)

1. Adding new scenes dynamically. Clear scene, play animations within scene, hooks to add stuff into scene, sequence scenes. eg: loader scene, intro scene, game scene, anim scene etc. So there can be a scene manager who sequences scenes and effects transitions between them.

2. Ability to log with some external logger like arthropod.

3. XML based fps, screen size, background color settings. Or they should be able to be changed at a central location.

4. Ability to skip levels, skip scenes, invincible mode with out life loss, ability to add score in a 'DEBUG' mode. These need to be cleared in release.

5. Centralised variable updations, to check bugs. This should output logs.

6. Centralised sound controls, in order to efficiently stop sounds globally. This also outputs log.

7. Centralised movement control for all scene items. This can help a lot with collisions tracking and scene rendering. Can opt stuff out when they are out of scene.

9. A bitmap renderer which only draws scene sized bitmap of current game stage. This optimises and speeds up rendering and controls frameskipping.

10. Reserved variable for eg, 'path' which gets populated with the path to external data using html embed codes.

Here is the walkthrough video for level 4.