oranjoose

RE: TilingSprite issue I got it to work by putting in the game.addAsset statement for the graphic file. Why is addAsset required for TilingSprite but not ordinary Sprite? On a separate note, is there a convenient way to add physics to particles emitted, without having to create a custom particle class and custom emitter for those particles? Thanks!

@mirage29 When I do this code: game.createClass('Panda', 'Sprite', {texture: 'panda.png',myObject: { myObjectProperty: 10 }, init: function(x, y) {this.position.set(this.myObject.myObjectProperty, y);this.addTo(game.scene.stage);}, update: function() {this.position.set(this.myObject.myObjectProperty, this.y);}, changeMyObject: function () { this.myObject.myObjectProperty = 300;}}); game.createScene('Main', {init: function() {var sprite = new game.Panda(100, 100);sprite.changeMyObject();var sprite = new game.Panda(300, 300);var sprite = new game.Panda(500, 500);}}); It's not changing myObject.myObjectProperty on any of the other instances--it only changes the instance on which I called the changeMyObject member function. Am I misunderstanding your question?

Weird. I still can't seem to get it to work. Downloading the most recent version of the develop branch and using the exact code from the Playground with a panda.png downloaded in the root, it won't work. Erasing "Tiling" to make it a normal Sprite works just fine. Having the "addAsset" function above also seems to make the load hang even when it's just the normal Sprite. This is tested using Brackets and WebStorm's built-in local server on Windows 8 with Chrome and Firefox. Not sure what I'm doing wrong.

@goide Thanks for the reply. Did you test this yourself? I've done that and it doesn't work on my end. enpu stated a few weeks ago (on page 9 of this thread) that TilingSprite was "almos[t] done" while providing a link to a working TilingSprite playground. Maybe it's still not quite done?

Is the TilingSprite class available yet? I downloaded the latest version of the develop fork, but when I try to instantiate a TilingSprite, I get a "TypeError: Cannot read property 'resolve' of null" console message. It fails on something like this: var bg = new game.TilingSprite('graphics/bgImage.png', 200, 300); Am I somehow doing this wrong? Thanks!

Wow, nice updates enpu! As Ninjadoodle said, if it's a plugin, then I don't think anyone should have anything to complain about; it's only a good thing. I'm guessing most developers don't need whatever performance they'd get from WebGL for their games, and we're now saving on resources. For the config, I think you meant "game.config" instead of "game.confg", though I doubt you threw anyone off. I like how you still kept the config.js file in the default project. That keeps main.js cleaner, and generally speaking, I think beginners think of configuration to be in a different place, such as settings in games, preferences in programs such as Microsoft Office and Adobe applications, and so on. This change hardly affects the way people are doing things now, but also makes the engine more well organized and gives more flexibility. Win win. Blend modes, yay! This is great for light effects, such as a better flashlight than a half transparent sprite. Happy to hear that it's integrated. TilingSprite! Very nice. I was actually going to ask about such a feature. Tilemaps are great, but they can be a bit confusing to a beginner. A tilingsprite is a much softer step for beginners (tiled Windows backgrounds, CSS backgrounds repeat by default, and so on). I like it. Container and FastContainer, Sprite, TilingSprite, and PhysicsSprite—I think I'm picking up on your design philosophy here =). I like that you're being consistent with it. Consistency is important for someone to be able to guess where to go in the API when they are looking for something, like a detective getting into the mind of a criminal or something, you know, not to imply you're a criminal =P. The only very slight criticisms I have about it are 1) none of these related classes line up alphabetically, so it might be easier to overlook them, especially as the API gets larger. It might be worthwhile to strategize how to organize documentation so that people browsing it can find relevant classes easier. Like on Amazon.com or something, "see related items". I mean, that's not a good example, but you what I mean. 2) a pattern I noticed, and I might be wrong about it, is that the classes are distinct from each other in that you can't take a Container and make it a FastContainer, and you can't take a Sprite and make it a TilingSprite. If this is true, then isn't it slightly inconsistent that you can take a Sprite and effectively make it a PhysicsSprite? But I'm torn, because I really like the idea of PhysicsSprite, and I advocate it. I'm just pointing out an observation, and am curious to hear others' input on it too. Updated docs and even a book, great! I've noticed that you have information about the engine all over the place, but it's kind of tucked away. There are the 2.0 docs, but you have to dig in threads to find it. There's also a cheatsheet; there are the demos (really like these); there are even sample projects if you search hard enough. Right now, Panda feels like one of those towns that look barren and uninteresting from the highway, but once you turn off and drive into the heart of the town, you see that it is really wonderful and cozy. I understand you are working on a new site, and you are also not ready to transition 2.0 as the standard version. Once you are ready for these things, an organized "learn" section could go a long way to attract newcomers. It might even be cool to have a more interconnected documentation system. Nothing super ambitious. What I mean is to have links to demos in the documentation, or maybe comb through the docs and put in an example of usage or give a tip on for each method or property. Or maybe it could be even faster and more powerful to have the docs crowd-souced in some way. For example, each property and method could have a separate page of its own when you click on it, with a comments section of users leaving code snippets and tips. I contend that the documentation is one of the biggest draws to PHP (here's an example page: http://php.net/manual/en/function.sort.php ). Okay, now it sounds like I'm asking for something more ambitious =P. I'm not, you can keep it simple. A solid product is better than a solid user manual in my opinion. And maybe you can just funnel people to your book! Haha. Seriously, just keep up the good work in the direction you're already heading. Great work on all these new features!

@enpu I really respect how much you listen to the developers working with your engine. But you know what's better for the engine than anyone here, so I recommend you go with your intuition. That same intuition has led us to this engine, which I as a teacher have considered more intuitive than any other JS game engine I've reviewed, and I've thoroughly reviewed a ton of them, big and small. I agree that magic steps that obscure what's going on is generally inadvisable. However, there's a line of course, where some of the "what's going on" is just needlessly confusing. For example, with C++, you have to do all the header includes and so on. This is material where I would tell students "now you have to type this and this and this, but don't worry about it for now." I hate doing that. One thing I like about Panda is that the setup is very straightforward. Beginners don't have to micromanage the HTML head and elements, they don't have to worry about all the extra references and game object setup. They can just open up main.js and go. Very clean. The body factory game.Body.fromSprite is definitely more simple, and avoids manual Body and shape instantiation. But I'm on the same page as you with adding unnecessary avenues to the same thing. In fact, this is what I think is the biggest weakness with Phaser. Phaser has too many ways to do the same thing. It begins to get confusing to a beginner when 5 different tutorials explain 5 different ways to accomplish the same task. The beginner becomes overwhelmed by the API documentation, confused about the "right" way to do anything. For accommodating beginners, I'm always an advocate of fewer tools, more steps than more tools fewer steps. For example, I'd rather a bunch of simple blocks to create something complex, than a huge pool of specific blocks. Simple legos instead of super specific legos. Unreal Tournament few weapons that are distinctive than Call of Duty tons of weapons that all do the same thing. I mean, think about game design. We build worlds that initially offer very few choices, and by the end, the gamer has a lot of options. If only a game engine could be built like that! No one expects a beginner to jump into World of Warcraft playing as a super high level character with 100 spells and buttons on the HUD. No matter how many great tutorials there are for Unreal Engine 4, it doesn't make the engine any less intimidating for a beginner trying to make a simple game. That being said, I like the direction Panda is going. The game.Body.fromSprite function is convenient and probably harmless, but it's a slippery slope toward the Phaser problem. I am fine either way. Whatever is chosen, my recommendation would be to go with something clean and simple, that accommodates at least 90% of people needing that functionality, and to then advocate that approach in demos and examples. The fringe developers then have to work harder to do more obscure things with the engine. This is my general recommendation for just about everything in the engine. The whole physics body stuff isn't terribly critical, it was just a thought trying to reinforce "simple and clean," which is clearly something that you value. A much bigger concern of mine for my students, for example, is the ease of designing levels (such as placing obstacles, items, NPCs, and various other objects). I am not bringing that up right now because I understand you're working on something already. So far, the best I have is to have students create levels in a graphics editor (such as Illustrator), and write down coordinates to manually put into their Panda games. Far from ideal, and I'm researching alternatives now. Thanks again for the great work!

@PixelPicoSean I suppose you're right. Though I'm trying to avoid as best as I can to create "magic" steps or libraries that are outside of what the students can expect outside the class . But I suppose it can't entirely be helped. Thanks for the suggestion, and thank you enpu for your great work on this engine =).

Thank you for the quick reply! Yes, creating such a class is very easy for me. I was making the suggestion as a teacher of students just getting into game programming, heck, even just plain old programming. I like how Panda is structured to eliminate a lot of needlessly abstract code, and instead appeals to the average non-programmer's mind. However, with simple physics, there are a lot of statements that in and of themselves are pretty simple, but collectively take a toll on the beginner. To illustrate what I mean, reading bottom up, the beginner probably assumes that the body should automatically stay the same position as the sprite, and therefore position copy is perhaps confusing at first. Of course, you don't necessarily always want a physics body to follow the sprite, but most of the time, I think gamers are conditioned to expect it. Then the idea of removing the body when you are removing the object. I'm guessing the beginner assumes that the garbage collector should automatically remove the body when the object is "removed." Understanding the keyword "this" is already enough of a mind trip for lots of newbies, so the line this.parent.removeChild(this) is particularly taxing on a beginner's mind. I mean, I can go on, but I think you get what I'm at least trying to say. Sure, it's my responsibility as a teacher that the students understand these concepts, but the timing of when these concepts are unrolled is more restricted when they are hit by them before they can make a simple platformer, for example. Thanks for acknowledging my thoughts. It is much appreciated. I completely understand if the suggestion is impractical or outside the style of the engine's structure.

Hi, if you don't mind, I plan to post a request/suggestion for Panda every now and then. I had trouble choosing whether to put them here or in individual new threads. I guess I'll just put them here for now, as this thread has to do with developing the new version. I can make new threads if that's more appropriate though. Anyways, here's my first suggestion/request for now: One command simple physics switch. Since simple physics (for collisions at least) is pretty common, it might be nice if there was a more straightforward and intuitive way to activate it. For example, maybe when you extend Sprite, along with supplying a value for the texture or interactive property, maybe there could be an autoPhysics boolean property that triggers a lot of the boilerplate statements that maybe the majority of people do for basic physics, i.e. create a body named body, set its position to the position of the sprite, create a rectangle shape the same size as the sprite texture, add the body to the world, remove body when you remove object, etc. This is surely not the best way to do this, but I couldn't help but feel that all these extra steps just to get an object with basic collisions is a bit of a barrier to a beginner. At the same time, I also wouldn't want to start a slippery slope of all sorts of easy toggles all over the place. Just thinking out loud.

I thought the playground was broken too, but actually one of the links that enpu put on the previous page doesn't work: http://ekelokorpi.github.io/panda-site/engine/playground/ The working link is almost identical: http://ekelokorpi.github.io/panda.js-site/engine/playground/ . I added in bold the difference. Hope that works!

Playground appears to be broken again<eom>

@Pooya72 To clarify, the default 512KB limit Tern sets for the files it uses for autocomplete is less than the phaser.js file which is over 2MB, therefore Tern does not parse it for definitions for populating the autocomplete. However, the phaser min file, it being significantly smaller, could very well be parsed by the Tern autocomplete engine, so it might just work to make sure the phaser min file is in the same directory as your project source files. The other option I suggested was to change that 512KB limit by creating a new file with the name ".jscodehints". To change the size limit of files the Tern engine will parse, you can include { "max-file-size": 3000000 } in the .jscodehints file. Reload brackets and this should hopefully do the trick.

Hello, quick question: is there a way I can assign a mouseover/inputOver event to emitter particles? I couldn't seem to find it for emitters. Thanks

So I think I figured it out. The max file size for what Tern analyzes is 524288 bytes by default, and Phaser is over 2000000. You can adjust this by creating a new .jscodehints file in the root directory. The config is a JSON block, and the one I did to make it work, at least partially, was this: { "max-file-size: 3000000 } It may work to just use the minified file instead.