Tuesday, April 23, 2013

So, kinda a big change.

After months and months of working on Pathogen we have come to the realization that I built it on the wrong kind of foundation. There had been warning signs, questions raised about "Why can't we animate this?", or "Why is it running so slowly?".

The answer is that Flash Professional was never meant to create full fledged games, animations/prototypes yes, but full games no. The reason is the Flash Display List. Every time you call addChild(thing), that object is added to the display list. It doesn't matter if all of those children are being drawn to a parent object, each is being drawn individually through the Flash Display List. Which means that every frame (in our case 24 times a second) the whole of the flash display list is being redraw. In a normal game that breaks down into each "tile", all 228 of them on a small map is being redrawn, each of those tiles have a grid space, so double that, add the player selector buttons as well as the GUI objects and your talking somewhere in the realm of 500+ objects being redrawn every frame for just a small map.



This limitation is what causes those little loading hiccups when switching map sizes on the game setup screen as well as loading a game in general.

It also limited the number of artifacts we could have moving around in the background, how fast the slider responds, and was one of the big reasons why we decided to ditch phone development.

So after a long talk about it, we have decided to address the problem. The answer is to virtually rewrite the game using a known flash engine such as Citrus, Starling, Flash-punk  or Flixel.  These engines are created in such a way that all assets, no matter their number, are all drawn at the same time and thus drastically increasing efficiency. 

The first step in the process is research. What do these different engines have to offer, how active is the community, how well does it integrate, etc.

After a few frustrating days of testing we have come to a decision, Pathogen will be rebuilt using the Starling AS3 Framework.

Why did we choose Starling? Well, it had a lot of things going for it.

1. Adobe seems like they wholeheartedly officially support the engine, which means in the future they may plan with it in mind.

2. The community is pretty strong, a lot of big name games (Angry Birds) have been created with it and there are some great tutorials out there.

3. It mimics the native Flash syntax, addChild, EventListener, all has a Starling variant making it far easier for me to switch my thinking over to a newer system.

So a wide new world await us, tomorrow I will be talking about my experiences in getting Starling working(not an easy task) as well as what the big code changes will be making the switch over to this engine.

 

No comments:

Post a Comment