Home > Dev > PushButton Engine

PushButton Engine

Probably old news but I’ve just found some time to read about the recently released pushbutton engine, a modular ActionScript 3 engine tailored especially for game development. It seems that Jeff Tunnel & Co (of Garage Games fame) were sitting down and wrote some serious ActionScript library overnight.

“…and a component system which lets you easily package game functionality into reusable modules. The component system draws on nearly a decade of game development history…”

This looks very promising indeed and the component structure makes a lot of sense.

I’ve been working on the hexagonLib on and off but time is sparse currently and so it seems I would never get it into a decent release state. I Might as well see how the pb engine works out for me. Let’s see how this engine fits for my current role-playing game project!

  1. May 6th, 2009 at 12:44 | #1

    I have been intersted in looking into it as well just haven’t had the time with school, work and other engines like unity3d and iphone stuff. I am very interested in if you find it valuable. Should you dig in be sure to post on it!

  2. ninjascience
    May 6th, 2009 at 13:51 | #2

    I checked it out and was turned off by the coding standards, which are way outside the norm for what most AS programmers are used to. Apparently they are going to change that though, so you may want to wait for the next release. I’m working on my own component system so it was neat to see how someone else is doing it in the same language.

  3. May 6th, 2009 at 14:04 | #3

    I haven’t delved much into their code yet. Can you tell whats the prob with their coding standards?

  4. May 6th, 2009 at 14:39 | #4

    @ninjascience – our bad on the code formatting but we are going to re-format EVERYTHING to be more standards compliant. It think it should make it into the next (or next) release ;)

    –Rick (PBL)

  5. ninjascience
    May 7th, 2009 at 00:37 | #5

    yeah Rick! good for you guys! Purely from a developer adoption standpoint you guys made a good decision. IMHO, it’s not a matter of the quality of the engine or the code you write for it. From what I can tell the thing is really solid. PNW FTW

  6. May 7th, 2009 at 00:58 | #6

    Thanks for checking out the engine and your feedback. We are all very excited about the PushButton Engine. It gets really fun when you hook it up to the multiplayer server which runs the same ActionScript code, so easy!

  7. May 7th, 2009 at 13:57 | #7

    I looked into this engine over the weekend and was not impressed. The coding convention is very unorthodox, and the current functionality is poor at best versus individual libraries already out there. Right now, until they come out with some amazing new beta, it’s all marketing smoke and mirrors to me. HaXe is the way to go if you really want to make a nice game with Flash Player since the performance is better than AS3.

  8. May 7th, 2009 at 20:48 | #8

    @Jonathan what I like about this engine is that’s it’s made by some gamedev veterans (well, at least Jeff Tunnel is one that I know of) and that they’re using this component-based approach. It’s just a first version! Give the project some time! No engine/lib was perfect from the start.

  9. May 8th, 2009 at 04:15 | #9

    Sascha: Thanks for the post and kind words. :)

    The combined industry experience amongst the five of us is something like 60 years. You can check out our bios at http://pushbuttonlabs.com/about/ – there are certainly stronger teams out there, but I wager the average Flash game team does not have the depth of experience we have.

    Jonathon: I’m sorry we didn’t impress you. I appreciate you listing the areas that we fell short for you. We’re going to be redoing the code style soon. I’m not sure what functionality you’re referring to as poor; the engine is designed to wrap existing libraries, so most of the “big” functionality is provided by good existing stuff like Box2D. We’re not trying to reinvent the wheel – there are good physics and rendering libraries already. Our goal is to make it really easy to bring that stuff together to build your game.

  10. May 8th, 2009 at 05:48 | #10

    Hey Ben, I am pleased to see one of the developers here on the forum!

    Here is my biggest worry: performance. Using the latest FP10 and shaders for Math processing, frame rate can still drop into the gutter in no time. Plus, using a framework usually means slower performance as there is an API acting as a proxy to the actual functionality… meaning you will loose performance since you have to call the framework that has to internally rap libraries like Box2D. Take a good look at Ffilmation (or even PV3D). Even super simple levels can bring Flash Player to its knees. With haXe, this isn’t a problem as you can inline functions so that a framework has no overhead to the player. If you are serious on building a game library, at least use haXe for the core library and have a SWC for Flash developers. Otherwise, no matter how the library is made, a serious developer will pass it up because of faster performance directly using 3rd party libraries like Box2D.

    Maybe I am just complaining, but for me, even haXe with FP10 and shaders can hinder me in performance when trying to remake a game that’s over 15 years old.

  11. May 8th, 2009 at 06:25 | #11

    I try to be everywhere people are talking about PushButton. :)

    We definitely have reviewed PV3D and a lot of other Flash middleware. That’s one reason why we are focusing on integration instead of doing our own high performance physics/rendering code. :) The stuff out there is really good!

    What would HaXE speed up for us? It definitely is nice, but it’s also non-standard. We really want to make PBE accessible to every Flash developer, which means supporting the standard tools is a big deal. Now, if Adobe bought out HaXE and put it into their toolchain, we’d switch in an instant…

    About 90% of what we do is lookups in dictionaries, which is native code. In our games and demos, we spend much more time in Flash’s software renderer than we do in AS3 code. Even in Grunts, which has a lot of pathfinding and spawning/moving objects, most of our time is spent outside of AS3 execution – and when AS3 does take up more time, it’s one of two things. Either it’s a specific hotspot – like the pathfinder – or it’s the GC.

    For the GC, our plan is to integrate object pooling into the engine so that you can avoid costly allocations and have less GC activity. This can be a major savings (http://lab.polygonal.de/2008/06/18/using-object-pools/).

    For hotspots, using HaXE is definitely an option. But the hotspots aren’t from the core PushButton Engine framework – they’re from game specific elements that are added on, like a pathfinder. PBE will work fine with HaXE-authored components, which I think is a much more sensible approach for performance sensitive routines.

    But you aren’t seriously arguing that doing a hundred Dictionary lookups per frame is going to bottleneck your application, are you? That’s largely what the core engine does. Everything else is modular and could be written as HaXE code or whatever you wanted. That’s what the engine is designed for.

    (BTW here are the games that came out 15 years ago, in 1994 – http://www.mobygames.com/browse/games/1994/ – it seems to me any one of them would be very straightforward to remake in Flash, even plain old Flash9/AS3. Some good games that year. Battletoads, X-Wing and Tie Fighter, Sam & Max Hit The Road, X-Com.)

  12. May 8th, 2009 at 08:55 | #12

    Sorry, I was thinking more of 1996 around the advent of Duke Nukem 3D, Warcraft, Descent and Wing Commander.

    haXe allows you to really tweak your performance like using functions (inlining) that have zero cost of performance when Flash needs to repeatedly call the same function. Generics are also super handy for a game engine (you might need to google this as its hard to explain). Also, haXe libraries can export to SWCs that can be natively used (with tooltips) with Flex and Flash CS4. (but you loose CS3 and below which I can see being a concern)

    While the game engine manager may be an elaborate Dictionary system, the modules being created (which are what users are mostly hyped about) will take a performance hit since they all have to be keyed from the internal lookup table to return a response. I need to look deeper into the source before I can say exactly how much. Using haXe, you could employ polymorphism with the game modules by having the manager class use generics. As long as the modules use inline functions inside, you might actually take close to 0% performance hit.

    Wow, I really sound like a haXe promoter here which wasn’t my intention. However, it does have a lot of promise for advanced users that want to tweak the heck out of Flash Player.

    If every module is being stored in a Dictionary, you might have many many calls per frame if module need to talk to each other. For example, an AI module may need to query a MapGrid module for all the AI units… then it might need to reference a Collision module for checks. Again, I need to do more research on your engine before I should fully criticize it though. :)

    Some general speed tests:
    http://pixelwelders.com/blog/best-practices/2008/speed-tests-objects-vs-arrays-vs-dictionaries/

    Don’t get me wrong, I would LOVE to see this project succeed. I am just pensive on how a overlaying framework on top of existing modules that are already too slow for basic games can ultimately help.

  13. May 8th, 2009 at 09:17 | #13

    You should probably review it more closely. :)

    The system is specifically designed to let you avoid the dictionary references if you want to. It makes the code a little more brittle but if you really need the extra few % you gain by using direct references, it is ready to go and there is a fairly clean way to do it. In practice the flexibility is well worth the small performance hit.

    In my experience even a thousand dictionary lookups per frame is not a major performance hit compared to the overhead of rendering one sprite. Even according to the speed test you link (which unfortunately does not mention which version of Flash it is testing, or what CPU he is on), that only eats 15% of time at 30FPS. And I know that it is not that bad in practice, because I can run Grunts at 60hz without the JIT on, and it’s doing quite a few dictionary lookups per frame.

    Generics are cool. I’ve worked with metaprogramming in C++ and C#, and looked over the HaXE stuff, too. You can get a lot of mileage out of it. But if your biggest overhead in PBE is the plumbing (component/property lookup) you’re doing it wrong – probably subdividing into too many components. And, of course, you can go purely reference based if you’re willing to have compile-time dependencies for everything.

    The inlining in HaXE is cool as well but it only applies to situations where the compiler has enough knowledge to make type inferences. The major win of a component based system is that you can combine the components however you like, and reuse them in multiple ways in the same game. For instance, the different enemies in Grunts are made from a set of components combined in different ways. You don’t know at compile-time how they will be combined so the opportunities for inlining aren’t available, even with a compiler as good as HaXE. But it won’t matter – because plumbing isn’t where your execution time goes, it goes into things like pathfinding or rendering or physics or AI.

    My point with all this is to say that I think that a game built with PBE is going to be just as fast as one built without it, and a lot easier to maintain and extend. While Flash itself has definite performance limitations, a little OOP-driven dynamic binding is hardly the kiss of death. Surely a Gang of Four devotee who maintains his own MVC framework can see the benefit of a little structure in an application. :)

    Obviously, writing a 3d renderer or physics library in HaXE has obvious benefits. But PBE doesn’t actually do much computation; it just helps other things compute.

  14. May 8th, 2009 at 10:44 | #14

    Well Ben, you do speak wisely. I will hence refrain from further commenting on the engine until I have some time to dive into its inner workings (perhaps this weekend sometime). Do you have an email address or preferred forum in which I can resume contact when I have done my homework on the source?

    Personally, I am a huge AI developer buff who becomes frustrated a bit when Flash Player chokes when only rending single pixel representations of AI algorithms and behaviors. :)

  15. May 8th, 2009 at 13:57 | #15

    Definitely. Come by the PushButton Engine forums at http://pushbuttonengine.com/forums – it’d be great to talk more about it once you’ve had a chance to check it out in a little more detail. :)

    PS – It would be super cool if someone wrote some great AI components. We are launching our component store soon – it’s like the iTunes App Store, but any developer can put components on it.

  16. May 9th, 2009 at 03:16 | #16

    Whoops – it’s actually http://pushbuttonengine.com/forum – my bad!

  1. No trackbacks yet.
You must be logged in to post a comment.