• Content count

  • Joined

  • Last visited

About Parasyte

  • Rank
    Advanced Member

Contact Methods

  • Twitter

Recent Profile Visitors

268 profile views
  1. You only have a few options for saving; Save and load from localStorage; melonJS provides a wrapper for this. Create an HTTP REST API to save and load from your favorite database ... or directly rewrite the TMX/JSON files Option 2 is really cool if you are saving directly to the TMX/JSON files, but doing any of that is way outside of the scope of melonJS.
  2. Movement will only follow the path that you define. You should be able to get some visualization very easily by drawing the path with the canvas lineTo() and stroke() methods. When your path is drawn the way you expect it, then getting the entity to follow that path is a piece of cake.
  3. This would admittedly be much easier with ECS. As a short-term workaround, the DraggableEntity is already an entity; it has a body with no shapes. Add your shapes to its own body. If you want to add shapes when the draggable is created, just pass an array of shapes as settings.shapes to the DraggableEntity constructor.
  4. Can you clarify? It sounds like the vectors are defined in orthographic space and you want to convert them to isometric space, is that correct? We have some convenience methods for these conversions: vector2d.toIso() vector2d.to2d()
  5. There's a public API for removing shapes: You can also change the shape in-place (and save yourself a bunch of CPU cycles and garbage collection overhead, if you're doing this often):
  6. The primary way to achieve this (function currying) in JavaScript is through closure bindings. But I think what you really want is to imply the state from the caller. E.g. whoever is calling `` should be responsible for passing any arguments to the next state. In the original example, only a single argument can be passed, and that's the `dt` delta time. Likewise, all state methods receive the `dt` argument first, as you can see in the `fsmUpdate` implementation. It can be extended to pass arbitrary arguments on the `next` and `fsmUpdate` methods. I'll leave it up to you to play with, but the magic `arguments` reference (and Function.prototype.apply()) will help you here. Optionally, you can use rest parameters if you're on ES6. There's one tricky point that will probably catch you off-guard, though, and that's that every state executes every frame. So your wait method gets called every frame and it will create new timers on each call (notice your `this.waitTimer` is not nullified until the timeout expires). Remember that the state machine *is* state, so you should create a timeout and immediately advance to the next state (which simply does nothing). When the timeout expires, it advances to the *next* state which will continue doing useful work. This is the only state you need; conditions like `if (this.waitTimer !== null)` are kind of useless in a state machine.
  7. What are you trying to do with it? Everything is draggable *and* droppable? How do you resolve ambiguities when dragging two objects into each other simultaneously with multitouch inputs?
  8. Unfortunately I think it's just going to be a matter of writing code. Code to support tile collision shapes, or code to automagically create collision shapes as you add roads to the scene.
  9. Just update the code to melonJS 4.1.0! Here are the changes I can see just by looking through the code on github (I haven't tried it): me.ObjectEntity -> me.Entity this.maxVel -> this.body.mexVel this.vel -> this.body.vel this.accel -> this.body.accel update method -> accepts a single argument named dt (delta-time) this.super() -> this._super(me.Entity, 'update', [ dt ]) this.updateMovement() -> this.body.update(dt) And here's the update guide, which will help you for any other problems you might find when running old code with a new library:
  10. Collision shapes defined by the Tiled Collision Editor are not supported in melonJS. I had to do some digging through old tickets, but the decision was basically "this feature has high difficulty and low value", so we punted on it. The current workaround is defining all collision shapes on the normal collision layer, as seen in the tutorial. This does have the benefit that your collision shapes will actually be visible while creating your map (this is not currently supported by Tiled for Tile Shapes). And another bonus is that you have more freedom of control over defining the collision boundaries; e.g. use a single PolyLine object to define the shape of the wall or the house by tracing the object borders (vs hundreds of small shapes). For example, this screenshot shows how we use BIG shapes that cover multiple tiles. This ends up performing far better at runtime than hundreds of small shapes, and it also allows us to be lazy and not worry about writing a bunch of code to merge shapes. The only downside is that it may create some duplication of effort for level design; e.g. every rock or tree needs its own collision shape anyway, and if you decide to move them, you have to move the tile and the shape separately.
  11. Try to bind it: "fsmUpdate" : function (dt) { /* Call current state */ this.states[this.fsmIndex].bind(this)(dt); },
  12. You can recompute the path if there is an object in contact with it and the object is close to your path-finding object (with some threshold). In short, recompute the path when it is potentially blocked in the immediate future. This might create non-optimal paths, or even unreachable destinations, so keep that in mind. Use me.Line objects to create collision triggers along the path, and recompute the path on collision AND distance between object position vectors.
  13. Oh, you're using DOM elements. That explains it.
  14. It sounds like you will want to implement some state manager for changing between modals. We have a very rudimentary state manager for the overall game (e.g. title screen -> play screen -> game over screen, etc.) You won't be able to use it directly to manage modal menus. But you can use it as a guide for how to implement such a thing at a high level. Some other tips: Menu systems can often be implemented as a stack, where a "back button" will take you back to the previous menu, and allows for a great deal of depth for complex navigation needs. Simpler navigation UIs can be implemented with as little as a single variable to store the "current menu". Try not to get too crazy with it. (Personally, I am not a fan of menu-driven games like classic RPGs. I prefer games to be fun, and selecting items in a menu is not fun.)
  15. Out of curiosity, what did you do to fix it?