1
Frima Studio2
Session Takeaways Iterative pre-production process is good for you How to think mobile How to keep multiplayer simple ...
Sprint Oriented Session4
Brainstorm Workshop5
Overview - Brainstorm Workshop Target device Technology to use Flash Stage3D vs other technologies Past Adobe Timeline...
Target device Cross-Platform Web iPad2 and up for iOS Nexus 7 and up on Android Sub-Platforms Amazon OUYA SHIELD7
Android Performance 30 cycles = 9 FPS Epic Citadel Shadowgun Dead Trigger8
Profiling and Debugging tools9Adobe ScoutNVIDIA PerfHUD ESIntel GPA
Technology Engine Connected backend ActionScript programmers Seamless ports High risks Heavily change renderer Numb...
Stage3D GPU Reach Stage 3D GPU Reach FP11 : 60-70% FP11.2 : 70-85% FP11.4 : 90% WebGL WebGL support on mobile is wea...
Art adjustment Art problems A guy allergic to peanuts Who probably lives with his mother Art = later Placeholders12
Adobe Gaming Recap13
Brainstorm Conclusion14 Recap It’s cold where we work Target iPad2, Tegra3, Web Android GPU performance reality check...
DisclaimerLorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam nibh tortor, posuere in facilisis at, consequat s...
Sprint I16
Overview – Sprint I Feature Creep Animation Driven Locomotion Gameplay Placeholder everything Attack without animati...
Creep Marching square Running on Android Initial = 150 ms Opcode (Azoth) = 20 ms 8x8 Partitioning (2 - 4 ms) 64 Mesh...
Character motion (ADL) Problem Foot sliding Solution Animation Driven Locomotion How Tools and exporter20
Foot Sliding21 3d Studio Max exporter using AMF C++
Power walking22 Get the programmer to like it Still give control to the designer Artist feared it would looklike Power ...
Sprint Conclusion24 Flash can be fast Optimized opcode uploadFromByteArray Customize your flash experience Create plu...
Sprint II25
Frame by frame animation Inspired by Quake Cons Bigger file Lots of buffers No IK Solver Pro Faster26
Faster but Why ? Skeletal animation Each frames setProgramConstantsFromByteArray (All bonesId and Weight data) Frame b...
Networking in IceField28var xml:XML = describeType(cTransform);…<variable name="mBaseDamage" type="Number"><metadata name=...
Networked crowd Network everything! Easy But 50k/sec29
Networking in IceField30 Getter and Setter Data synchronisation Pre-Processor
Sprint Conclusion31 Something Old In 1996, Quake introduced mdl 3D spritesheets Sometimes a good Pro override many Con...
Sprint III32
Overview – Sprint 333More…More Crowd for me……
ZombieTycoon34What they remember:• 2000 Zombies• Stage3DWhat they should…• Intel i7• Dedicated video cardAnd now:• Mobile•...
Crowd35 Zombie A* on a 2D Grid Neema Navigation Mesh Using Flascc Granular flow movement Back to 2D Grid No A* su...
Crowd movement36Will not work on
Critter mower38 Worked but too heavy Sword as collider Sphere collider Solution Pre-Computed hits position Per Anima...
39Critter mower
Critter mower40
Critter mower41For (Crowd pos){Grid[pos]=beiber}
Critter mower42For (Hit pos){Grid[pos]=dead}
Avatar43
Sprint Conclusion44 Generic technique Know them but… Do something else Mobile > FarCry Requirement
Sprint IV45
Multiplayer and networking Network tools UDP vs TCP Peer2Peer Network interpolation From 50k to 5k / sec46
Latency Built-in Network tools Latency metrics47
Built-in network metrics48
Network tools Microsoft Network Monitor49
Network tools Network Emulator for Windows Toolkit Latency Packet loss Network errors50
Network tools http://wanem.sourceforge.net/51
Network techniques High Bandwidth Intervals CPU Hog Limit packet size Latency Kills Network interpolation Predict p...
Sprint Conclusion53 Make networking behave Use networking tools to simulate latency Use interpolation for position of m...
In the meantime in R&D…54
Using 2D in a 3D game Flash Display List 50% CPU on Android Starling Easy to Implement 6% CPU Can’t block Click55
ASC 256 Better Incremental build by default Swf size (-35%) Performance (+15%) Stricter compilationvar Roger:uint = -...
Other choices57 Red Tamarin Updating as we speak API on top of Redux https://code.google.com/p/redtamarin/ Play Scrip...
Less known features ANE GameCenter InApp purchase Push Notifications Rate this app flasCC Epic citadel Existing Al...
GLSLTo AGAL compiler GLSL2AGAL https://github.com/adobe/glsl2agal Existing Shaders No need to go low-level! Some rece...
Stage3D Modes Facebook https://www.facebook.com/groups/stage3d/ Extended July: Rectangular textures Texture size : 4...
Do it ! Be Agile Fail Fast Be Proactive Create Issues Be Different Tailor Flash Be Creative This is The Creativity...
SESSION SURVEY on the MAX COMPANION app …for your chance to Win e-Books Win Apple iPod Nano.62
63
Mastering Multiplayer Stage3d and AIR game development for mobile devices
Mastering Multiplayer Stage3d and AIR game development for mobile devices
Mastering Multiplayer Stage3d and AIR game development for mobile devices
Upcoming SlideShare
Loading in …5
×

Mastering Multiplayer Stage3d and AIR game development for mobile devices

1,876 views
1,795 views

Published on

Video Presentation : http://tv.adobe.com/watch/max-2013/mastering-multiplayer-stage3d-and-air-game-development-for-mobile-devices/

• The use of Stage3D across web and mobile deployments (with Adobe AIR) .
• The challenges encountered when attempting to maintain high-performance specifications on mobile devices .
• Being agile in a pre production game development
• We'll show how we have jump our of the predefined sandbox to develop creative solution on well known problem.

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,876
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
12
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Thanks for coming to our session today.We appreciate that you chose our talk today, we knew you could pick a Shockwave or Cold Fusion session instead.We’re glad you stuck with Flash.Before we get started, we’d like to know more about the crowd we have here.Show of hands, who’s a programmer? Who’s an artist? Who’s a designer? Any business folks?I’m Luc, CTO of Frima Studio and since I lost a bet, here is JP.
  • Alright, le me briefly talk to you about Frima.We are located in Quebec City, right over there on the frozen part of North America.We are currently freezing over 350 people there.Just so you know, in Quebec, we have two seasons.We have Winter, and then we have July.So plan your travel accordingly if you want to visit us.
  • Here are the main takeaways for our talk.If you don’t know it by now, iterative game development is a must!We’ll also show you how to think mobile-first in your development process.Multiplayer is cool, but it can be expensive to add to your game, we’ll give you tips on how to keep it simple.Our game is built in Flash and we think it will be awesome 
  • We said just now that Iterations are good for you, and if it’s good for you it’s also good for us.For this project, we decided to use short sprints and focus on a few things at a time.We will use these sprints as sections for this talk, hopefully making things more interesting for you.
  • Let’s start with our brainstorm session for the game.We decided to do a 2 days offsite meeting with the key members of the team in order to define the brand and decide on the main directions for the game.We wanted to get everyone on the same page.
  • Those are some of the main points that came out of that brainstorm session.We had to define our minimal target devices, what technology we wanted to use and also we made some art adjustments based on our initial prototype.We’ll talk about the decision process around what technology to use.Obviously, we decided to use Flash, otherwise we would not be here at MAX today.
  • We wanted our game to be Multiplayer-multiplatform so we want to target iOS, Android and the Web.On iOS, the iPad2 gave us everything we wanted and then some.On Android, we went for Tegra3 devices and up so that we could get the same experience on both iOS and Android.Also, it would open the door to other Android-based platforms like the Kindle Fire, OUYA or nVidia SHIELD.
  • Our previous prototype was not performing well on our target Android device, it ran at 9fps.By profiling great mobile games such as Epic Citadel, Shadowgun and Dead Trigger, we found out that we used too many cycle count per pixel in the shaders.So we made choices and we used clever techniques to reduce them without cutting on visual quality.
  • Normally, we always keep profiling for the end of our talks, but since we felt like changing the world today… Here it is!Performance profiling tools are your friends, we used nVidiaPerfHudES on Android, Intel GPA for the Web portion and Adobe Scout for our overall CPU performance.We still have no tools for GPU profiling on iOS, let us know if you have some.So make sure you use these tools as early as you can in your production. Don’t wait till the end.
  • Like with every projects, we had to decide on the technology to use in order to target all those platforms.We had an existing engine using Flash and connected to our backend engine.We had a team of ActionScript developer ready to go.We wanted our “ports” to be seamless between platforms.We also knew that this project would require a very specific rendering pipeline in order to show 100+ avatars on the screen.Same thing on the crowd system for that many units.So we decided to use our in-house Stage3D technology because we knew we would require the flexibility to tailor it to our needs.
  • Let’s talk about about Stage3D GPU reach on Desktops for a moment.There is a couple of nice articles with results on that.In brief, it shows that the initial release of Stage3D, with it’s 2009 driver date restriction, had a reach of about 60-70%Then Adobe moved it back to 2008 and we got a nice 10-15% gain.Finally, Adobe added Constrained mode and driver dates to 2006 and we got a nice 90% sweet spot.On our side we did similar sampling on some of our existing live Flash games and we got similar results backing those up.[CLICK]If we compare with WebGL, the reach on mobile is not even at 10% and on the Web, it’s not more than 70% of the browsers, let alone older video cards.[CLICK]The Unity plugin is also an option, however, their installation based is less than 20% of Flash player. Depending on your audience, the willingness to install it can be small.http://renaun.com/blog/2013/04/how-far-is-the-reach-of-webgl-on-the-desktop/
  • During the workshop we had to review our character design from our previous concept art so we went in a slightly different direction.Because our initial design made our male avatar look like a guy with peanut allergies who probably still lives with his mother.However, it was decided that art would not be integrated into the game, until the basic game feel would be in place.
  • Because of all of this we selected Stage3D as our technology. Doing so, it reminded us of the past history of Stage3D and we wanted to share with you our vision of it.
  • We hope you enjoyed our weird Stage3D timeline…Anyways, here’s a quick recap of our brainstorm session.It’s definitely cold where we work.We decided that iPad2 was our minimal iOS target and we choose Tegra3 devices on Android to match that.We hit some issues with GPU performance on Android and with profiling tools, we figured out where to cut.Speaking of profiling tools, use them, they are your friends!And on the tech side, Yes! We decided to use Flash!
  • Alright, so here’s our Disclaimer.This talk is not about selling our internal technology. In fact, we don’t even sell it ;)The main aspect of this session is to show you, with examples, how to leverage Flash to get the most out of it.We wanted to push the limits of what we can achieve in Flash.This is what we did on the Web and now we are doing it on mobile.And we want you to do the same.
  • The focus of our first 2 weeks was on the character movement and the dynamic creep system,And even though the animation was not technically a big challenge, it was the first time our production team worked with our new animation system.In the mean time, a gameplay programmer was implementing many place holder.After two weeks, we got this (video).
  • The Creep is that goo on the ground, and we wanted something that look organic, like it could spawn from everywhere like an infection.We look into many solutions but The Marching square turn out to be perfect for that. The marching square is a algorithm that create contour meshes from a squalar field.I won’t go into the detail of the implementation, and this image come directly from Wikipedia. But instead I’ll talk about what we’ve done in flash to make it efficient.Now because it consist mostly of lookup table, it is already very fast.However, as fast as it can be, it is still too much to be dumbly implemented in as3, when we did it, it ran a 6 FPS[CLICK] First thing we’ve done it to take all our Vector access and convert them into byteArray and used optimized opcode with Azoth, Why not, remember, it’s royalty free again.This led to 8x gain in performance (great) . But still it was too much too keep a decent frame rate with the rest of the game logic.[CLICK] This algo was creating a huge mesh every frame, so the next step we took, was to slit the big mesh into a smaller grid, thus creating 64 different meshes. We then compute the algorithm only when it is visible on screen.[CLICK] And if you make sure to use uploadFromByteArrayinstead of uploadfromVector,you’ll keep decent performance, even with multiple dynamic meshes
  • Here the result in slow motion
  • Now lets talk about animation. But first a little bit of context.Every time we started a new 3d game, we will always have one comment about the foot sliding of the main character very early in the productionLet’s first get an example of foot sliding pushed the extreme.[VIDEO]The programmer can decide the speed and the direction of the avatar regardless of the animation. And this led to the feeling of a floating character.For this project, we wanted to get that right at the very beginning[CLICK] For this, we’ve given the production team an Animation driven locomotion system. With this system, it’s the animation that define how fast you character can move and it is well known in AAA console and PC game.[CLICK] But I will not explain how to do an ADL, but instead how you can create tools or exporter to get flash to do what you want.
  • Most authoring software gives you the possibility to create custom interface or exporter.To fix our foot sliding problem, we created an exporter in 3ds max that saves a small dummy node while exporting the animation.This little node follows the avatar throughout its animation and record the movement at every frame.Now, this exported file can be read at runtime, and the node movement can be apply every frame to the character while he plays the animation.The nice thing is that because the exporter uses an AMF writer coded in C++, and AMF if the adobe file format, so flash can understand the output from 3dsmax as if it was written by flash itself.
  • Now that we fixed a problem, we created many new ones, the first was that the programmers were used to move the character as they wishes. And they did not like the fact that they needed to go through an art pipeline only to change the speed on the avatar.But, same goes for the designer, he wanted to try different speed in different situation, and they could not without the animation being re-exported from 3dsmax.That was not very efficient, but at the same time, the artist didn&apos;t want the speed of the animation to be modified by a programmer because they feared that this would make it to the final game, and that we would blame the Art team for a walk cycle that look like this.Guess what, he lost it, at that time he was alone against many programmer and designer, we gave the programmers 2 ways of specifying the movement speed.First one, It a function that choose which animation to be played and how fast it will be played depending on the requested speed.The second one is more interesting, because it uses an interface created in C# to talk to flash.
  • There is a speed multiplier that can be applied to any animation, and because the speed is driven by the animation, the speed is affected at the same time.One thing we tend to forget is that flash can uses socket, and socket can be used in localhost. So you can create an application in any language that can talk with your running flash game.In his example, we’ve uses c#, but could be anything,
  • To conclude this sprint.Flash can be fast, you’ll see more in the upcoming slides, but we’ll have one of the more Action packed game on mobile game and it is build in stage3d.But also, Flash can really do what ever you want, you just need to customized your pipeline with the correct tool, that you modify or create according to your needs.
  • In this sprint, we added a couple of concepts and features, but the most important thing were:- How to deal with massive crowd of enemies on mobile devices- And- the addition of basic network
  • In order to show 100 enemies on the screen on mobile, we could not rely on skeletal animation techniques, this was way too heavy.So we decided to inspire ourselves with old formats used by the Quake engine.Basically, we used a frame-by-frame 3D animation. Kind of like a spritesheet in 3D…This technique had a lot of cons. Bigger file size, larger memory footprint and since it was not bones-based, we had static animations only.Lots of cons, but all that matters here is the speed. So we went with this solution.
  • Why was it faster?Skeletal animation known as skinning or animation with bones requires you to send bones weighting at every frames because your animation changes.This is heavy since we need to send constants from the CPU to the GPU at EVERY frames for !every! animations.Frame by frame animation has a slightly longer initialization time since you have to upload the vertex for the whole animation at once, but only requires you to tell the driver what buffer you want to use before you draw it, no CPU to GPU transfer required. The same texture is used on all frames, so it’s still lighter than traditional sprite sheets.
  • For easy synchronisation of gameplay features we decided to use simple metatags in our ActionScript code.When editing a scene, the programmer identifies the game objects to be synchronized over the network. Using our game editor, we then flag those objects as “Network Enabled” meaning that, upon loading the scene, the engine will parse those object for values to be sent over the network.The reflectivity in Flash is awesome. What’s cool is that by calling the simpledescribeType function, you can read a class definition in XML, including our added metatags.
  • Now it was time to network all of that good stuff!With the metatag method that we talked about earlier on, we created a networking solution out of the box meaning that, by a single checkbox, we can create a multiplayer experience..The tricky one to network was the large crowd.Because, as easy as it may sound to add multiplayer, we got 50k/sec transfer rate.For fast prototyping, it’s no issue, but we knew we had to work on optimizing what we were sending.
  • Let’s say a gameplay programmer wanted to network, say the damage taken or the position of an object, they wold simply add the tag on the Getter/Setter and the engine would take care of the rest. To synchronize the data, the programmer needs to assign a value to the variable and then set the flag NetworkDirty on the class. The engine then updates the value on all the remote clients. It is also possible to modify values coming from the network before and gets processed by the gameplay code, using a callback function. This is useful for prediction and interpolation functions.And about that image… while we were preparing the presentation, I saw a typo in a variable name, so I asked the team to make a fix for our presentation.They asked me if I wanted them to do the presentation for me, and sent me that.I’m kind of rusty in programming, but I think it should work…
  • In conclusion.When building a game, the reflex to look at all the new and shinny things is not always a good one.Sometimes, looking at old techniques can give you insights to solve your problems today.And remember, sometimes a good Pro will override many Cons.Also, try to make your networking solution, Gameplay programmer friendly.It’s very important to keep iterations fast.Also, keep in mind that you might need someone to look at optimizing what’s sent over the network, but that step can be done later on.
  • And we made a bet involving popcorn and movie tickets.I’m looking forward to a free movie soon…
  • From what they remembered, we had thousand of zombies in our first prototype.What they should have remembered is that this was running on a desktop I7 with a good dedicated video card.And now, this crowd needed to run on mobile and it need to be networked.
  • There was two challenge with the crowd, movement and attack, Lets start with movement.Previously, In the Zombie Tycoon molehill demo, we had Simple A* for all the enemies on a single grid and this was working fine on decent computer for up to a hundred of stupid zombies.In Neema, we removed the grid and create a Navigation Mesh instead. It was using the c++librairies detour and recast compile through flascc, this gave us better control over random terrain and over/under bridges.However, for endless waves of brainless critter on mobile, we removed the Navigation Mesh and the A*, and implemented a simple granular flow algorithm, we’ve seen similar algorithm like this in a small flash game called sugar sugar.
  • Here come’s the programmer Art time to define in 1 slide the technique. I’m sure scientist in the granular flow field would kill me if they were to hear that.Let’s keep that between us.But, in short, The reason why this is efficient is because the green circle only care about it’s immediate surrounding not an inch further. So at every frame the movement possibility is very small and very fast to test.This however will not work for any complex terrain where A* might be required. Even this very simple example. Where the green circle wants to joined the blue one.
  • In action, this look like sand particle.In this example they are all moving in the same direction, but they don’t need to, it just creates a better looking demo.If you create obstacle or bucket, they will stack until they can move on the side, that is as far as there “intelligent behavior”
  • Now that we have our enemies moving, how do we hack and slash our way through them to make them stop? The easiest solution is to use the sword as a collider and test with all enemies but mesh to mesh collision is way to much.Also, we could add a sphere collider on the tips of your sword, and test for collision with the enemies bounding volume. We’ve done that in the past, and it is working, but is not very efficient for mobile.Instead we pre-compute a list of impact position and export it with the animation per frame.
  • And to do that, we created a tool in 3dsmax, using maxscriptthat create a impact cloud for every animation frameWe can see that on the left, every little cross represent a possible hit position. and on the right we show the impact area of a complete set of animation.Lets quickly see in programmer art how this work in the game.
  • Remembered that we talked about a 2d grid for the flow movement.This is the same grid but we added our Heros.
  • Next, we add our worst enemies per dozen.
  • We reproject the impact cloud exported by 3dsmax on the 2dgrid and simplify the collision test to a simple vector access. With this, it’s easy to define which Bieber was hit.
  • Event though the collision is not pixel perfect they wanted to achieve the feeling of waaaaaaaaa, and it worked.
  • Once again, when we thought about developing flash game on mobile, we knew we would need to find alternate solution for well know problem like collision or movement. You should step out of the predefined sand box offered by commercial engine. And create your system differently.An Ipad today is more powerful than yesterday console and PC. There is no reason we can’t do great game on it.
  • We though we were good on networking after our first few sprints, but our tests didn’t seem to agree on that.We wanted to make sure the game was working on low-latency and on less than optimal network conditions.Well, it was not.
  • After our network tests, we knew we had to look at networking tools to help us out.We also looked into UDP versus TCP, and Peer2Peer solutions, but those two are the subject of a talk by themselves.Le me show you what we did to get the game to work well in all network conditions.
  • The first thing we had to do when looking at networking tools was to decide which ones we could build into our toolset.Not every networking conditions can be simulated using frontend profiling tool, but we figured that some of them are worth it.For instance, in our engine, we added built-in support to add latency and the ugly but very useful graph you see here is our tool to visualise it.
  • On top of that latency tool, you can see here that we added built-in networking metrics straight into the engine so that our developers could see what was going on in there.They could see bandwidth and in and out packets with some stats to show averages and total counts.This allowed our developers to react quickly as they were adding network features.As failing fast is key in iterative development.
  • Now that we’ve seen some of the tools that we created on our own, we don’t need to reinvent the wheel as there are already lots of tools out there.For example, you can use network monitoring tools such as Microsoft NetMon to watch your packets and inspect them.This gives you a great insight into what is passing through and doubles as a network debugger.
  • And for advanced network simulations, you can use the Network Emulator for Windows Toolkit, allowing you to add not only latency, but packet loss and errors.This way, you can simulate bad network conditions and make sure that your game reacts well to them.
  • Finally, you can also setup a server-side proxy that will allow you to set Latency, packet loss and all kinds of funky network issues.In order to set your workstations to use it, simply put the IP of the server as a proxy and you are good to go.This proxy can, ad maybe shoud become an integral part of your QA process.
  • Enough with tools.Remember we talked about the 50k/sec, that was for 2 players and we wanted 4.So we really needed to reduce the bandwidth.For that we added the possibility to send the data at specific intervals instead of every frames, thus drastically reducing the messages sent by second.At specific point in the game, when lots was going on, one frame could be flooded with network packets thus overwhelming the CPU on mobile because of the decompression. To fix that we limited our packet size per frame and delayed the rest for the next frames.Network latency combined with our interval method created a game that didn’t look smooth at all.We decided to use interpolation based on the speed and direction to smooth the experience.Since our networking implementation allowed the coders to build a callback function that would intercept the incoming position of the characters, they could make an interpolation based on direction and speed.Let me show you a video that helps visualize it.
  • As a conclusion to this sprint, I’d like to bring back the importance of making your networking almost transparent to your production team.And provide them with tools so they can see what’s going on under the hood.At the same time, have some folks test the game under different network conditions so that you ensure that your game will behave properly in all cases.When making a real-time multiplayer game (or any games that require calls to a server) always test it by simulating latency and packets loss.This way, you will ensure that your game will work with the worst network quality and the best 
  • This was the end of the pre-production part of our talk, but we’re not done yet!While our production team was hard at work on the prototype, our R&amp;D team was supporting them, however, we also had time to look into more advanced stuff.This section will go through those topics, some of them quite experimental.
  • We’ve tested ASC2 when is was still codename falcon. At the time, we had problem.But now that they release it, it Rock.I suggest that you look into it, because it simple is better.It reduces your file size, increase your swf performance significantly.It even have a stricter compilation rules, making you code better.
  • Even though we select stage3d for this game, we are still developing game for windows 8 phone, xbox, vita and playstation. And Adobe will probably stay away from those target. Now, With stage3d, we use less display list and 2d rasterizer. Because of that, Tamarin, the open source Virtual machine look more and more attractive. Because it can run your AS3 game on any platform.Red tamarin is a wrapper on top of Tamarinredux that offers you some API like socket and filesystem. The owner of red tamarin is updating to the latest version of the VM as we speak.Also, Zinga released playscript to the opensource community recently and there is already a couple of framework working with it, like away3d and Starling. This also offers you the possibility to compile to many platform with very few changes in your code. I’m looking forward to this initiative.According to http://ingweland.com/playscript-benchmark/playscript is 3x slower
  • There are a couple of less known features that are not using ActionScript as the primary language but offer you a great possibility to extend your Flash application.Remember that ANE allows you to build your own native extensions and use them in AIR.Many existing extensions offer you features out of the box, do check them out.flasCC allows you to compile C++ code into Flash. A great way to leverage your existing codebase.And we’ve seen a good example of that with the unreal engine.I don’t want to minimize your project our ours, but if they can compile their M+ lines of code, I’m sure you can do it too.Since AIR is still single-threaded and that most mobile devices have 4 cores nowadays…We believe that ANE might be a solution for Multithreading on iOS and Android.We will soon start to dig into this option.
  • The GLSL To AGAL compiler is used to compile GLSL shaders so they can be used in your flash application. It’s open source and on github.If you have existing GLSL shaders that’s a great tool to use.If you are converting an existing C++ game to Flash using flasCC, there’s a good chance you’ll have to use this too.You don’t need to go low-level by using AGAL, GLSL will provide a high-level language to make your shaders.We had to work on the existing compiler and took the time to make a couple of fixes while we were there.We will soon make a commit on github.
  • Couples day ago I sent an post on a very busy Stage3D group on Facebook asking what people want to hear about at Max. Every answer were about Roadmap.I wish I had a crystal ball also, and Especially after some of the latest public announcement, we were a bit concerned.So we just had a call with Bill Howard from Adobe and after the call we were reassured.Adobe is still putting a lot of efforts in Flash and AIR, they are still pushing incremental changes on all of these.For instance, Stage3D Extended is still in the pipeline, but ubiquity is a issue. However, Some part of it are to be release in July, like Rectangular textures 4K textures.What’s next? With the stories about Action Script Next, They are more reluctant on putting stuff too early on the roadmap, but features will keep coming..And we’ve heard that some really cool things are coming.
  • In conclusion.Be Agile.Implement quick iterations, this will allow you to fail fast, adjust your sight and build a better game.Be Proactive.You will have bad network conditions, don’t wait for them to happen, created them and fix your game around it.Be Different.Tailor the tools around you to create a unique game.And finally, Be Creative.Not only in your game design and art but in the way you approach and solve your technical challenges.After all, this is The Creativity Conference.
  • Thanks, please fill up the survey, not only can you win a book or an iPod, but you get to select “Awesome” as your session rating!
  • Any question.
  • Mastering Multiplayer Stage3d and AIR game development for mobile devices

    1. 1. 1
    2. 2. Frima Studio2
    3. 3. Session Takeaways Iterative pre-production process is good for you How to think mobile How to keep multiplayer simple Flash is still a good option Your happiness is important3
    4. 4. Sprint Oriented Session4
    5. 5. Brainstorm Workshop5
    6. 6. Overview - Brainstorm Workshop Target device Technology to use Flash Stage3D vs other technologies Past Adobe Timeline recap Art adjustment from initial prototype6
    7. 7. Target device Cross-Platform Web iPad2 and up for iOS Nexus 7 and up on Android Sub-Platforms Amazon OUYA SHIELD7
    8. 8. Android Performance 30 cycles = 9 FPS Epic Citadel Shadowgun Dead Trigger8
    9. 9. Profiling and Debugging tools9Adobe ScoutNVIDIA PerfHUD ESIntel GPA
    10. 10. Technology Engine Connected backend ActionScript programmers Seamless ports High risks Heavily change renderer Number of enemies on screen Crowd system10
    11. 11. Stage3D GPU Reach Stage 3D GPU Reach FP11 : 60-70% FP11.2 : 70-85% FP11.4 : 90% WebGL WebGL support on mobile is weak http://webglstats.com/ Unity Plugin Depends on audience11
    12. 12. Art adjustment Art problems A guy allergic to peanuts Who probably lives with his mother Art = later Placeholders12
    13. 13. Adobe Gaming Recap13
    14. 14. Brainstorm Conclusion14 Recap It’s cold where we work Target iPad2, Tegra3, Web Android GPU performance reality check Profiling tools are your friends Yes! We use Flash!
    15. 15. DisclaimerLorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam nibh tortor, posuere in facilisis at, consequat semper leo.Morbi mauris massa, placerat dictum ultrices sed, pretium et sapien. Donec sed lobortis urna. Aenean malesuada nisleuismod odio euismod pellentesque. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpisegestas. Integer fringilla lacus ut erat pulvinar vitae porta risus aliquam. Sed vel suscipit nulla. Donec gravida felis aliquammauris rutrum ac luctus est viverra.Vivamus facilisis, orci ac sollicitudin dignissim, leo risus malesuada eros, nec tempus enim orci quis lacus. Lorem ipsumdolor sit amet, consectetur adipiscing elit. Nunc eget nunc id nisl ultrices cursus vitae sagittis lectus. Aliquam id lacus lorem.Aliquam erat volutpat. Aenean eleifend, orci eu tristique suscipit, risus mi vulputate ante, vitae porttitor nisi purusmalesuada velit. Nunc libero magna, iaculis id hendrerit vel, aliquam euismod nisi. Aliquam erat volutpat. Duis vel erat quiserat posuere fermentum. Integer a libero sed nisi ullamcorper vehicula id sit amet mi. Nullam ornare sollicitudin ante nondignissim. Quisque vestibulum massa ut mi cursus ut auctor erat sollicitudin. Cras lacinia, neque sed commodoconsectetur, nulla justo facilisis nunc, interdum dictum augue dolor sed dui. In vel dolor magna, eget volutpat ligula. Morbivulputate arcu sed mi luctus vehicula. Proin euismod mi sit amet diam commodo mattis.Donec non dictum elit. In hac habitasse platea dictumst. Integer commodo consequat nibh a luctus. Etiam est lacus, ornareeu tempus et, tincidunt vitae turpis. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptoshimenaeos. Integer pulvinar, erat ut tristique semper, quam justo congue lorem, quis mattis magna sapien at nisi. Cras urnalectus, blandit quis tincidunt vel, tristique vel urna. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuerecubilia Curae; Phasellus sed purus lectus.15
    16. 16. Sprint I16
    17. 17. Overview – Sprint I Feature Creep Animation Driven Locomotion Gameplay Placeholder everything Attack without animation Basic Character movement17
    18. 18. Creep Marching square Running on Android Initial = 150 ms Opcode (Azoth) = 20 ms 8x8 Partitioning (2 - 4 ms) 64 Meshes and Indexes Camera Culling uploadfromVector uploadFromByteArray18
    19. 19. Character motion (ADL) Problem Foot sliding Solution Animation Driven Locomotion How Tools and exporter20
    20. 20. Foot Sliding21 3d Studio Max exporter using AMF C++
    21. 21. Power walking22 Get the programmer to like it Still give control to the designer Artist feared it would looklike Power Walking Let them control the speed Avatar.RunAt(5 km/h).please(); Animation multiplier
    22. 22. Sprint Conclusion24 Flash can be fast Optimized opcode uploadFromByteArray Customize your flash experience Create plugins in Flash IDE, 3dsmax, Maya Connect to Flash with sockets Editors Debuggers and Profilers.
    23. 23. Sprint II25
    24. 24. Frame by frame animation Inspired by Quake Cons Bigger file Lots of buffers No IK Solver Pro Faster26
    25. 25. Faster but Why ? Skeletal animation Each frames setProgramConstantsFromByteArray (All bonesId and Weight data) Frame by frame Longer initialization time Each Frame Tell which vertex Buffer to use27
    26. 26. Networking in IceField28var xml:XML = describeType(cTransform);…<variable name="mBaseDamage" type="Number"><metadata name="Customizable"><arg key="type" value="decimal"/><arg key="label" value="Base Attack Dmg"/><arg key="min" value="0"/></metadata><metadata name="Network"/></variable>
    27. 27. Networked crowd Network everything! Easy But 50k/sec29
    28. 28. Networking in IceField30 Getter and Setter Data synchronisation Pre-Processor
    29. 29. Sprint Conclusion31 Something Old In 1996, Quake introduced mdl 3D spritesheets Sometimes a good Pro override many Cons Something New Networking out of the box Gameplay programmers friendly Still need tweaking for bandwidth
    30. 30. Sprint III32
    31. 31. Overview – Sprint 333More…More Crowd for me……
    32. 32. ZombieTycoon34What they remember:• 2000 Zombies• Stage3DWhat they should…• Intel i7• Dedicated video cardAnd now:• Mobile• Networked
    33. 33. Crowd35 Zombie A* on a 2D Grid Neema Navigation Mesh Using Flascc Granular flow movement Back to 2D Grid No A* sugar sugar
    34. 34. Crowd movement36Will not work on
    35. 35. Critter mower38 Worked but too heavy Sword as collider Sphere collider Solution Pre-Computed hits position Per Animation Per Frame
    36. 36. 39Critter mower
    37. 37. Critter mower40
    38. 38. Critter mower41For (Crowd pos){Grid[pos]=beiber}
    39. 39. Critter mower42For (Hit pos){Grid[pos]=dead}
    40. 40. Avatar43
    41. 41. Sprint Conclusion44 Generic technique Know them but… Do something else Mobile > FarCry Requirement
    42. 42. Sprint IV45
    43. 43. Multiplayer and networking Network tools UDP vs TCP Peer2Peer Network interpolation From 50k to 5k / sec46
    44. 44. Latency Built-in Network tools Latency metrics47
    45. 45. Built-in network metrics48
    46. 46. Network tools Microsoft Network Monitor49
    47. 47. Network tools Network Emulator for Windows Toolkit Latency Packet loss Network errors50
    48. 48. Network tools http://wanem.sourceforge.net/51
    49. 49. Network techniques High Bandwidth Intervals CPU Hog Limit packet size Latency Kills Network interpolation Predict position Smoother results52
    50. 50. Sprint Conclusion53 Make networking behave Use networking tools to simulate latency Use interpolation for position of moving objects Implement networking monitors
    51. 51. In the meantime in R&D…54
    52. 52. Using 2D in a 3D game Flash Display List 50% CPU on Android Starling Easy to Implement 6% CPU Can’t block Click55
    53. 53. ASC 256 Better Incremental build by default Swf size (-35%) Performance (+15%) Stricter compilationvar Roger:uint = -1;var Wilfrid:int = 0xffffffff;
    54. 54. Other choices57 Red Tamarin Updating as we speak API on top of Redux https://code.google.com/p/redtamarin/ Play Script Away3d and Starling First performance test are slow http://ingweland.com/playscript-benchmark/ https://github.com/playscript
    55. 55. Less known features ANE GameCenter InApp purchase Push Notifications Rate this app flasCC Epic citadel Existing Algorithms and codebase What about Multithreading?58
    56. 56. GLSLTo AGAL compiler GLSL2AGAL https://github.com/adobe/glsl2agal Existing Shaders No need to go low-level! Some recent fixes Matrixes support (up to 2) Dynamic access to vertex constant vc[x] Fixed m33 operations Fixed nrm on constants59
    57. 57. Stage3D Modes Facebook https://www.facebook.com/groups/stage3d/ Extended July: Rectangular textures Texture size : 4096 What’s next? http://www.adobe.com/go/flashplayer_roadmap I heard that… But…60
    58. 58. Do it ! Be Agile Fail Fast Be Proactive Create Issues Be Different Tailor Flash Be Creative This is The Creativity Conference61
    59. 59. SESSION SURVEY on the MAX COMPANION app …for your chance to Win e-Books Win Apple iPod Nano.62
    60. 60. 63

    ×