From Web to Mobile with Stage 3D

Editor's Notes

• #2: LUCHi everyone, thank you for joining us. We are happy to be speaking again at GDC Online.Welcome to From Web to Mobile with Stage 3D.I am Luc the CTO of FS, a 350 people game studio in wonderful Quebec city and since it was cheaper to send two people, this is JP principal something something.
• #3: Some definitions to get started.For those of you that are unaware, Stage3D is an API in Flash 11 that enables hardware acceleration (GPU).AIR, is a way to package your Flash game for multiplatforms, including iOS and Android.
• #4: LUCIn this talk, we hope that you will leave with 3 main takeaways.We want to show you why Stage3D is a valid option to make a mobile game, but also a multiplatform game.We would also like to show you tips and tricks to publish or transform your Web game into a mobile game.And finally, we’ll share some experiences we had to tune performance along the way.Last time, many folks told us that the talk was a tad too technical, so we decided to tone it down a bit, I’ll let JP get started on something simple.Transition to JP
• #6: Right, remember I told you it was cheaper to send two people?This is the timeline we’ll walk you through during the session
• #7: LUCThe project we will show is code named Toro. Let me quickly provide you with an introduction to what this project is.In brief (take paper out), it’s a multiplatform, synchronous cooperative multiplayer hack-n-slashwith support for drop-in drop-out.To get you started, here’s a quick trailer video.GAMEPLAY VIDEO
• #8: LUCThe project we will show is code named Toro. Let me quickly provide you with an introduction to what this project is.In brief (take paper out), it’s a multiplatform, synchronous cooperative multiplayer hack-n-slashwith support for drop-in drop-out.To get you started, here’s a quick trailer video.GAMEPLAY VIDEO
• #9: LUCObviously, we want the game to be fun and addictive.We want to game to be multiplayer, in coop mode with support for drop in, drop out.Finally, we want this game to run on Facebook as well as on mobile devices.
• #10: Why go to all the trouble of being multiplatform for a Web game?
• #11: LUCFirst, Facebook has very large and growing user base, and it’s public seems to be waiting for the next big thing in gaming.The project aims to prove that new-generation Facebook games can live and interact with mobile devices.Also, by targeting tablets, we open the door to support Smart TVs and other devices.Here’s a quick look at Facebook progression in the last few years.
• #12: LUCOh sorry, that was their stock priceHere’s the real thing
• #13: LUCHere’s an actual graph on Facebook progression.That’s a lot of folks to target!
• #14: In June 2010, this was the expected outcome on the unit shipment race.Somewhere in 2012, the inflection point would happen.
• #15: However, the reality was a tad earlier. SmartPhones and tablets were outselling PCs at the 4th quarter of 2011.And who knows how Windows 8 will affect that growth.Transition to JP
• #16: JPThank you Luc for stating the obvious…Now, that we know all that, why choosing Stage3D to make a project on multiplatform.
• #17: First Flash and air give us the largest reach with the same code base.But also, Compared to native, Developing a game in ActionScript is faster and less error prone.For instance, we want to focus on gameplay before memory management. Usually when developing for ios, you need a mac, but we’re a PC company, With stage3d our development team can work on PC and then publish to all platform.IF your game requires some interfaces, and they’ll probably do. with flash we can use the same vector based asset on all devices.And Adobe tools are awesome for interfaces
• #19: With nice 3D rendering, efficient gameplay programming and functional network features it is clear for us that Stage 3D is a good option when creating a game for multiplatform.
• #20: LUCNow that we are set on the tech, we need to have an efficient production pipeline to work with.
• #22: Thanks Luc,Everything that you can build or use that will remove hiccups in the pipeline will pay of.However, I will not talk about everything an editor should have, but only the features that gives us the more bang for the bucks. Fast iterations is the key in game production, even more for these 3 races of people.
• #23: First and foremost, your artist.We have heard too many time that they are waiting for the next programmer’s build to see their art in action.OR that the build don’t have the latest asset because someone forgot to copy the files manually.If they were only one thing that you could do to help you artiste, you shouldhave an art pipeline that is streamlined. From 3dsmax to the editor that support light, material, shader, animation everything need to be in place for them to iterate. But Also, If you don’t want them to wait to see the result in the actual game, try using the same renderer as your game within the editor, with this, you make sure that what they see is what they get. Here is what I mean when I said streamlining the pipeline.
• #25: Your game Designer are often neglected in tool production, In our case, I know they were. Probably because what they do don’t affect visual quality, or because they can finally reach their end by playing the game over and over and over again.But, If your designer is seating next to a programmer and tell him where to place the new spawn point or how many damage a minion should do, they both are not as efficient as they could be. Instead create tools that let them change those gameplay values rather than playing with an xml, but also let them place the spawn point and triggers that will start a cinematic or somethingHere is how it could look like
• #26: In most of our production, the programmers are the bottleneck of the project, not because they can’t create their feature on time, but mostly because they have to integrate art and design. By creating tools for the other tiers we have already freed a lot of time for them. The next thing you must have is a fast and convenient way of coding gameplay component. Scripting might be the way to go, around since , forever, With lua for instance, you could use this in your editor kinda like unity3D with c#. However, in flash there is no need to find another scripting language as as3 can be dynamically loaded. Here is an example: [VIDEO]
• #27: In most of our production, the programmers are the bottleneck of the project, not because they can’t create their feature on time, but mostly because they have to integrate art and design. By creating tools for the other tiers we have already freed a lot of time for them. The next thing you must have is a fast and convenient way of coding gameplay component. Scripting might be the way to go, around since , forever, With lua for instance, you could use this in your editor kinda like unity3D with c#. However, in flash there is no need to find another scripting language as as3 can be dynamically loaded. Here is an example: [VIDEO]
• #28: Oh one last thing, don’t let them do art.Seriously.
• #29: Oh one last thing, don’t let them do art.Seriously.
• #30: At Last, but not least, Our production teams are using SVN for versioning. SVN and the other versioning systems are not made for merging binary formats such as, in our case, our scene file.So often, developers are using locks to go around this issue.But in larger teams, locking a complete scene in the versioning system, is not very efficient as artist, developer and designer can work on it at the same time . Some editor provide you with a way of locking only certain part of the scene. But, what we think is the best solution to solve this problem, is to create a plugin to your versioning system that will support merging those types of files. SO that no lock are ever required. Here’s what we did.MERGING VIDEO
• #31: At Last, but not least, Our production teams are using SVN for versioning. SVN and the other versioning systems are not made for merging binary formats such as, in our case, our scene file.So often, developers are using locks to go around this issue.But in larger teams, locking a complete scene in the versioning system, is not very efficient as artist, developer and designer can work on it at the same time . Some editor provide you with a way of locking only certain part of the scene. But, what we think is the best solution to solve this problem, is to create a plugin to your versioning system that will support merging those types of files. SO that no lock are ever required. Here’s what we did.MERGING VIDEO
• #32: Now that we have looked at what’s needed in your toolset to be efficient, we will share with you some of the good habits we wish we had for our previous projects.
• #34: Don’t do QA using the debug targetThe debug target is faster to compile, so sometimes we tested using this version. Maybe because we were using lot of beta air version, but the debug target did not crash on every error. Meaning that we wasted our time We had to test anyway on the app store target.For faster iterations, however, #2 you should use the Debug targetIn general, to be efficient, you should be doing iteration on your PC, but at some point, you’ll need to do test on the device. For example, the touch interface. For that, use debug target and you’ll save a lot of compile time.#3 : The code running on IOS needs to be precompiled, So, loading code at runtime is not possible.There is a couple of ways and hacks to go around this issue, and even air 3.5 beta announce a better support for this. but we decided to take the simple path and compiled every bit of code in a single file SWF.Number 4 : Use compiler constantsThis one is straight forward, when building for multiple devices, compiler constant will give you the opportunity to have the same codebase for all platforms.For example : ifdef [IOS] use touch else use keyboard.
• #35: #5 On mobile, The garbagecollectorisevenworstthat on PC, If youthink about creating a gamethatgrowsbehondpac man, you’llneedtoo pool yourobjects.#6:At some point, Adobe will provide all of us with a tool that convert png to atf, a compressed texture format. It includes the texture for pc, ipad and other devices all in one file. This format reduce the bandwidth contention with the GPU as well as the VRAM. So, Use IT, but when you do, make sure that you blank out or remove unused texture format for your specific device. This reduces the ATF size by nearly two-thirds.You all know that, and I can’t stress this enough, #7 Test early, test often on your target platforms.For that, you can use build machine that compile every night for all devices, so that in the morning, your good to test with the latest version. Just to note; these same machines can also be use for continuous integration.With that said, you should be good to go.
• #36: LUCThanks JP, we are now ready to deploy our game!If you have not followed some best practices, the game might be polished on PC, and you might think that it can be deployed on iPad and work just as well.There is a good chance, that you will get a bad surprise like this one.If you had tested early and often, on the right platform, you would have found performance bottlenecks and applied some of the fixes we’ll talk next.
• #37: Several months back, Adobe announced their premium features.One of the main feature is when sing Alchemy, now flasCC, you can use C++ code in Flash!
• #38: When talking about performance in Flash, Alchemy is one of the first thing that comes to mind.We’ve shown at different conferences that we’ve used this to leverage the power of Flash.In the past, we’ve used this in Neema and Zombie Tycoon.For instance, we’ve use it to integrate Bullet as our physics engine.
• #39: We’vealsousedrecast navigation for ourpathfinding system and ourcrowd system.
• #41: Since 3 of our major modules were written in c++, it seemed logical to go that way and try it on mobile.Building using the interpreter target took some time, but it worked.The game took 1-2 minutes to load, and we realized that it was because of the mesh preparation. We optimized this by creating a simple collision mesh (a straightforward technique).After that, the game loaded in a much more decent time.
• #42: So far, we can say that it is working while compiling with the interpreter target, but at that time Alchemy was not released, and was a serious mess to debug.Also, the weight of the SWF was over 3MB for something that could fit in 300KB.However, we expected the performance to be vastly improved when building with App Store target. So we tried it. And we got: (neverending slideshow)After 36 hours of build time and a insane amount of RAM, the compilation stopped. We were never able to build the library in anything else than the interpreter.That said remember the good habits.
• #43: Lucky for us, AIR 3 adds a little thing called Native Extension.At that time, we had 4 weeks left to come up with a working solution for Physics, Pathfinding and Particles. So we started investigating it, with its ability to compile native code for mobile. It felt like a silver bullet.
• #44: But in fact it looked like this.Fred compiledthe Native Extension on Mac, sent it to a shared drive for Windows, compiled the wrapper in Flash, compiled the application in Flash and sent it to the iPad.The debugging process looked like this: We capture the error in Flash and then –pffff– black hole!Seriously, we had a simple project working, but when building big libraries, we encountered too many problems and random crashes and it was a mess to debug. Adobe is aware and working on it to make it easier.So we were stuck with no working solutions.
• #45: On the other hand, we wanted our Web game to be royalty-free, so using Alchemy or flasCC for the Web version was not possible.We thought we needed a full physics engine, but we ended up only using it for the ray picking related to character movement.Collisions were handled by the navigation systemEffects used tweening instead of physics.For the navigation system we would need to rewrite the game logic portion only, the editor was fine in C++.The particle system could not stay CPU-bound without opcodes, so we made a GPU-based one.
• #47: Here come’s the Last stretch on performance, but this time more low level on ipad hardware. For the cpu and gpu.
• #48: JPFirst, Here are some CPU-bound challenges we had and how we solved them. The pathfinding we had, took nearly 15 to 20% of our cpu time when all enemies were walking toward you. To fix that, we stored the navigation mesh in a bytearray, and run Azoth on top of it. Now the PF uses about 5% of our budget.A CPU based particle system was too much for our target platforms (even on the web without Alchemy if we wanted to be royalty free), so, we created a GPU-based particle system that worked fine on all platforms. And has a low footprint on the cpuThe garbage collector on mobile will cause spike in your performance graph, I think that was the biggest challenge we had. The team had to move, all the object creation at load time, and use pool as often as possible. Knowing that at the beginning of the project, we would have saved a lot of time.
• #49: On the rendering side of thing, One of the heaviest overhead on mobile GPUs using AIR are the States change related to DrawCalls.DrawCall batching is the solution for that, no rocket science here, but with the current computer hardware, people tend to forget, With AIR, it is very important.When aiming for Ipad2, overdraw can be a GPU killer. To reduce it, we need to sort the scene from front to back. And remove as much transparency as possible.Last but not least our GPU-based particle system was adding draw calls and overdraw.We decided to live with it. Now, a good-looking particle system will always demand a lot of power, from either CPU or GPU. You can reduce the particle count based on machine performance; like low-end desktop computers or tablet.
• #50: Here’s our summary on what are costly and cheap operations on mobile GPUs using AIR.Because Adobe Air add a layer on top of the 3d driver, so performance are not always what you expect them to be when compare to native. Every time you make a Draw call, there is a lot of state changes done under the hood making them very expensive.For comparison, modern game will have between 1000 and 2000 draw call per frame, running a 60 hertz on a good machine. With Air on Ipad2, if you could stay around 20-30 draw call per frame, you might get 30 fps. I know that this is an unfair comparison, but you get the point.Transparency worked but, use it wisely because it adds to the overdraw.Drawing 100Ks polygon and more is cheap, but make sure that you batch your draw calls.Normal and Specular mapping are commonly used techniques in video games, their cost is directly related to the number of instructions required in the pixel shader.GPU Particles, when used properly are probably the best way to go for ipadBut, as they are often rendered in group, they will create overdraw and add to the draw call. So, Your call,
• #51: Alittle slide on profiling. Profiling for Air on Mobile used to be a lot harder. Today, Adobe provides us with Monocle, a profiler that runs on the desktop and that connects wirelessly to any device. I can say that without it we would have never been able to deliver a game running smoothlyBut Regarding GPU performance, we had to rely more on Caveman debugging, and building our own real-time statistic viewer with on and off switchUnless you have a Android device running an Intel processor, then you can use intel GPA.For the desktop though, there is already a lot of good tools , we could use Intel GPA for the GPU and Monocle for CPU usage, which worked greatWe also used the Miner for day-to-day performance checkups, the miner will also work on mobile, the small interface is not very convenient.
• #52: It’s time to show it to you.
• #57: We’ve shown you some issues we had with Stage3D, however, we were able to tackle them all.But now that everything is figured out, Flash, Stage3D and AIR allows us to be very efficient for our multiplatform development.