Jump to content
Double Fine Action Forums
Sign in to follow this  
DF Oliver

Programming Update 10: Broken Age's Approach to Scalability

Recommended Posts

Thanks Oliver! This is great, please share all your geek ness with us!! :-)

I'd love to hear about how you guys structure your code regarding to moai, where would one start building a game like this, and still keep things organized? How would you structure your code regarding to basic engine stuff, but also level and scene files etc. ohw, this question just became a lot bigger then intended, sorry.

Also, do you bake the animation and 'play' the transformed vertexes or is the rig still present in moai and is it driving the vertexes?

Thanks for sharing this with all of us!

Diederik.

Share this post


Link to post
Share on other sites

I recognize that the Android platform is heavily fragmented, but I'm curious how much difference that makes in real terms.

For instance, is the fragmentation primarily due to hardware, and does it primarily deal with performance, or are there considerable differences in implementation and features?

Obviously, things slip through the cracks and glitches are expected, but is it reasonable to expect to "catch" these differences? Who is responsible for identifying differences in performance\features\hardware?

If the ecosystem is that fragmented but broadly identified as a single unit ("Android") through more-or-less a single distribution pipeline ("Google Play"), then how can you "ship" a product optimized for each implementation without exceedingly bloated shader code?

Share this post


Link to post
Share on other sites
If the ecosystem is that fragmented but broadly identified as a single unit ("Android") through more-or-less a single distribution pipeline ("Google Play"), then how can you "ship" a product optimized for each implementation without exceedingly bloated shader code?

I am not an android developer but my recollection is that the google play service allows the developer to have multiple builds for different devices. From there, it's a matter of clever use of preprocessor directives, makefiles, and other organizational techniques to cut down on bloat.

Share this post


Link to post
Share on other sites
Thank you for sharing this, it was a really interesting talk. I'm currently working on a 2D game for iOS and Android and we too had quite a few headaches when dealing with all the different Android devices. In order to handle all the different resolutions we identified all the aspect ratio groups we wanted to support (e.g., 1.77, 1.66, etc) and asked our artists to create assets for every group in the biggest resolution possible. Of course this method produces a lot of overhead for the artists, and the situation becomes more complicated when you consider the software bar on Android devices (it basically changes the aspect ratio). I was wondering if you guys faced that kind of problem and if you could share some of your experiences when dealing with it.

Yeah dealing with different aspect ratios is very important for us. We have the advantage that Broken Age has very little UI and that our main development platform is Windows and we made sure from the beginning that Broken Age can deal with every(*) window shape. Because of this it was relatively pain free to get the game running on mobile devices.

(*) Even though the game could run literally with every aspect ratio we constraint the game viewport to a sensible value between 4/3 and 16/10.

Share this post


Link to post
Share on other sites

When I hear you discuss weak Android devices, I'm excited to think I might be able to run Broken Age on my phone but I'm curious how anything will be legible on its tiny screen.

You are right. I think Broken Age will generally be more enjoyable on computers and tablets, but it'll run and be playable on phones as well. My hope is that it'll be okay since the game doesn't require that much UI. :-)

Share this post


Link to post
Share on other sites

I do wonder, though, will I be able to play my copy of BA on both my iOS device AND my Mac, or would I have to buy a separate copy if I wanted it for a second console as well?

That is a question for DF Greg... :-)

Share this post


Link to post
Share on other sites
I'm sure you've already seen it, Oliver, but recently there was a blog-post doing the rounds reporting on different vendors' support for OpenGL ES 3.0; to summarise, desktop GPUs and drivers are reasonable, mobile GPUs and drivers are terrible. OpenGL ES 2.0 is more mature and I'm sure more reliably implemented than 3.0 seems to be, but have you had similar issues with unexpected bugginess, as opposed to the predictable differences in raw power?

So far we had surprisingly few issues in this regard, which makes me very happy. One thing I ran into was a numeric accuracy issue in a vertex shader on certain Android GPUs. I expect to discover more of those issues as we are getting closer to launching on mobile devices and I can report back then.

Share this post


Link to post
Share on other sites
Is the zoom-in feature available in the final game or just the debug mode?

Just in debug and edit mode I'm afraid. ;-)

Share this post


Link to post
Share on other sites
Thank you so much for taking the time to do this. Is very useful to see in depth the technical process behind the game. I'm amazed you guys are able to take care of all this stuff. Also I would have banned Android if it where that unreliable and fragmented, this platform just can't be called one platform when you'll have to consider so many different devices and GPU's.

When it's done, I'd love have some Broken Age experience and see the world that you guy's made for us!

Hehe... programmer like a technical challenge, so it's fun in this regard. Also we promised it as one of the Kickstarter stretch goals, so we had to do it. Lastly the Android market is huge and will like grow in the future, so it's important for us as a company to figure it out.

Share this post


Link to post
Share on other sites

I'd love to hear about how you guys structure your code regarding to moai, where would one start building a game like this, and still keep things organized? How would you structure your code regarding to basic engine stuff, but also level and scene files etc. ohw, this question just became a lot bigger then intended, sorry.

Actually that was quite a natural process. The studio is used to organizing code and assets in a certain way, so we (mostly) followed along with that. The code structure was the easiest decision because of the way Moai is setup. Roughly speaking game-play code is written in Lua and performance critical (and systems) code is C++. :-)

Also, do you bake the animation and 'play' the transformed vertexes or is the rig still present in moai and is it driving the vertexes?

No we don't bake the animations mostly because it would take up a lot more memory than saving a bunch of matrices and then calculating the vertex positions in the shader.

Share this post


Link to post
Share on other sites
Which mobile GPU gave the most difficulty?

'Vanilla Android' which means any Android GPU that's not using a NVIDIA, Power VR or Qualcomm chip.

Share this post


Link to post
Share on other sites

For instance, is the fragmentation primarily due to hardware, and does it primarily deal with performance, or are there considerable differences in implementation and features?

Yeah we are mostly concerned with differences in performance and memory and not so much with features.

Obviously, things slip through the cracks and glitches are expected, but is it reasonable to expect to "catch" these differences? Who is responsible for identifying differences in performance\features\hardware?

That is an excellent question. The short answer is that we are responsible to identify and fix these kind of issues. Obviously it is unrealistic for us to own every device ever created and that's why we rely on QA and testing labs to do the brunt of the compatibility testing. That should get us 95% there and we'll need your guys help for the remaining 5% :-)

If the ecosystem is that fragmented but broadly identified as a single unit ("Android") through more-or-less a single distribution pipeline ("Google Play"), then how can you "ship" a product optimized for each implementation without exceedingly bloated shader code?

Zonr_0 is absolutely right. You can upload different versions of your app and based on the hardware in your phone/tablet the store will send you different files.

Share this post


Link to post
Share on other sites

I do wonder, though, will I be able to play my copy of BA on both my iOS device AND my Mac, or would I have to buy a separate copy if I wanted it for a second console as well?

That is a question for DF Greg... :-)

Ah, apologies. I'll have to send this question his way!

Share this post


Link to post
Share on other sites
Is the zoom-in feature available in the final game or just the debug mode?

Just in debug and edit mode I'm afraid. ;-)

it would be extremely helpful for playing on mobile devices. I hope it gets in!

Share this post


Link to post
Share on other sites
Is the zoom-in feature available in the final game or just the debug mode?

Just in debug and edit mode I'm afraid. ;-)

Based on what we've seen it would appear that the animators/scene scripters have access to the zooming though, right?

Share this post


Link to post
Share on other sites
Is the zoom-in feature available in the final game or just the debug mode?

Just in debug and edit mode I'm afraid. ;-)

Based on what we've seen it would appear that the animators/scene scripters have access to the zooming though, right?

Yeah definitely. :-)

Share this post


Link to post
Share on other sites

You already know we appreciate it, but again, thanks for taking the time to explain and answer questions!

Share this post


Link to post
Share on other sites

Can we get the 'zoom' and the 'see things in 3D' tools as cheats/unlocks in the final game? It would be awesome!

Or at least in the beta!

Share this post


Link to post
Share on other sites
Is the zoom-in feature available in the final game or just the debug mode?

Just in debug and edit mode I'm afraid. ;-)

it would be extremely helpful for playing on mobile devices. I hope it gets in!

...or a closer zoomed-in view on mobile to compensate for the small screen size and allow some panning... I'm sure it'll be great though, so no worries!

I could see myself playing this on PC at night on the big screen, then bringing up my saved game on tiny mobile device during the day. Anyone know about that possibility?

Share this post


Link to post
Share on other sites

This was really, really neat. I'm planning on taking a class on computer graphics next semester, so hopefully I'll be able to follow along even better then!

Share this post


Link to post
Share on other sites
we constraint the game viewport to a sensible value between 4/3 and 16/10.

Wouldn't it make more sense to constrain it between 5:4 and 16:9? Because those are the narrowest and the widest (common) aspect ratios in the PC world.

Share this post


Link to post
Share on other sites
we constraint the game viewport to a sensible value between 4/3 and 16/10.

Wouldn't it make more sense to constrain it between 5:4 and 16:9? Because those are the narrowest and the widest (common) aspect ratios in the PC world.

We chose 4:3 because it is our authoring aspect ratio and 16:10 because that's the widest ratio we've seen in the office.

Share this post


Link to post
Share on other sites
we constraint the game viewport to a sensible value between 4/3 and 16/10.

Wouldn't it make more sense to constrain it between 5:4 and 16:9? Because those are the narrowest and the widest (common) aspect ratios in the PC world.

We chose 4:3 because it is our authoring aspect ratio and 16:10 because that's the widest ratio we've seen in the office.

Does this mean that 16:9 will have pillar boxes? I am a 16:10 myself, so I don't have to worry, but I care about my friends with 16:9. Also, as 16:9 seems to be taking over, we will all probably be on it eventually. I know there would be some cropping, but will it at least be playable in these higher resolutions (by moving UI away from the top and bottom and then cropping the scene)?

Share this post


Link to post
Share on other sites
and 16:10 because that's the widest ratio we've seen in the office.

Don't you guys have that big ass TV in your meeting room? I'm pretty sure that one's 16:9 ;)

Share this post


Link to post
Share on other sites

You guys will be able to choose whether or not you want to see letterbox bars, so if you want to see all of the pixels even on a 16:9 or 16:10 display you can make that happen. :-)

Share this post


Link to post
Share on other sites

Excellent presentation! The insight, as always, is appreciated!

I'm just curious, you know all these crazy, clever little rendering techniques, are these just the kinds of things you pick up from experience or is there a lot of research involved when taking on all the little issues that come up? Granted, I'm a semester or two away from getting into "real" graphics programming, so a lot of it is still sort of Greek to me.

Also, do you know any good resources for graphics programming, mobile devices, or just anything that proved extremely insightful that you've dug up while making the game?

Share this post


Link to post
Share on other sites

I'm just curious, you know all these crazy, clever little rendering techniques, are these just the kinds of things you pick up from experience or is there a lot of research involved when taking on all the little issues that come up? Granted, I'm a semester or two away from getting into "real" graphics programming, so a lot of it is still sort of Greek to me.

I think it's a combination of research, experience and curiosity. I'm spending a good chunk of my spare time (which isn't that much these days) tinkering with various hobby projects and some of the visual effects I play with at home make it into actual games in the end.

In addition to that a lot of solutions come out of discussions with Lee and other members of the team. Talking about a problem (or rather desired goal) means you'll have to break it down which very often is 'half the battle'.

Also, do you know any good resources for graphics programming, mobile devices, or just anything that proved extremely insightful that you've dug up while making the game?

I think I mentioned it already in another thread, but I highly recommend:

Real-Time Rendering

Physically Based Rendering

Game Engine Architecture

The Art of Multiprocessor Programming

Share this post


Link to post
Share on other sites
You guys will be able to choose whether or not you want to see letterbox bars, so if you want to see all of the pixels even on a 16:9 or 16:10 display you can make that happen. :-)
Nice! Sweet deal. Nice to hear that you guys are thinking of a lot of what us adventure game fans want!

Share this post


Link to post
Share on other sites

Hi Oliver and thanks a lot for sharing the video. My main interest is in developing 3D games in general, but I find a lot of the ideas presented there very insightful. I have some questions about the video though.

- How many light sources are supported in the game ? I guess there is a loop inside the fragment shaders as usual to average the directions and colors of these lights.

- Your explanation of the shadow blobs and a rough polygon which encompasses these blobs to make them distorted was very insightful, but I wonder how you apply it to non-flat floors. Are there stairs in the game ?

- When you tried to compare the difference in performance between using chunks and not for environment objects, how did you do the experiment without the clip masks ? Was it just by loading large image files without doing any split ?

Cheers.

Share this post


Link to post
Share on other sites
Sign in to follow this  

×
×
  • Create New...