Mipey's Forum Posts

  • Or use system expressions - lerp is linear path, cosp is cosine interpolation, then there is cubic and quadratic, which are essentially bezier curves.

    cosp(P1,P2,t) interpolates between the two points - P1 and P2 - based on t, which represents the fraction of distance between the points (0..1). You can simply calculate a distance between the points, then iterate from 0 to 1 using timetelda (and a speed modifier). Then when you reach a waypoint, you move onward to next waypoint.

    Cubic and quadratic require more than two points, but you can always take another waypoint for reference (you get smooth turns that way).

  • I believe he meant destroying a part of the sprite, that is pixels, as in destroying a chunk of the boss ship with your attacks. I already provided an answer in the PM, however let me repeat it here.

    You can use a Canvas to copy the sprite image, paste a mask of the part onto it, then erase that part from the image and finally copy the image back to sprite. Don't forget to update the collision mask.

    However, this is an advanced game development topic and as such I wouldn't recommend it to beginners. You can try, however I won't offer much more help beyond this advice.

  • Have you checked the Ghost Shooter tutorial out?

  • Why, oh why did it have to be bees?

  • Edit time, I guess; states would be part of the engine, which is not altered in runtime. We'd have to define the state machines in edit time. There is no point in altering the state machine in runtime (at least none that I can see right now). Basically create sprites, families, stuff, then create state machines, maybe object or family specific, maybe free (to handle transitions, slideshows or whatever).

  • I think it is preferable that they are posted individually. What happens when one bug is fixed and other is not?

  • Sure, it is easy, but it is also tedious and I use it in nearly every project. It would cut a lot of development time down if there was a plugin for that.

    Moreover, I'd also like to have more or less independent FSM cells (one for each AI entity). It is easy to design AI using state machine, however in current form it is very tedious. Then some state machines run in parallel, so they shouldn't interfere with each other. For example game and GUI states, if you only use one global for states, as soon as you change the state, say open a game menu, there is a risk of breaking the game context.

    What I want is a FSM plugin that would allow me to create independent enclosed machines or one big huge tree of states, whatever suits the purpose. It would also make managing events easier - when your caveman is hungry, he goes to hunt, thus activate Hunt state machine which handles hunting procedure. As soon as it finishes, it returns to whatever the player was doing before hunting. Then there'd be interrupts, such as spotting a lovely cavewoman, then Romance state machine is invoked. Some interrupts would stop the current procedure altogether or just pause it and resume after the interrupt is completed.

    That's a lot of code to do.

  • Not enough dials and switches. You need more dials and switches if you want to go pro sound.

  • Hey, we need the bacteria to survive. Beneficial bacteria and all that in our intestines.

  • Destroy the animation once it is finished.

  • Finite State Machine is something that would trivialize several of major game development paradigms, which all projects could benefit from. Of course implementation with events and stuff is possible, however it basically would mean reinventing the wheel for each project.

    So a FSM plugin would be a welcome addition to Construct.

    How should it work? Here are a few concept ideas:

    a) Behaviour. Simply add FSM behaviour to an object, thus all of the object's transitions would be handled in a simple way. In event sheet we'd have access to defined transitions.

    Example: Sprite with FSM behaviour

    OnStart, OnStop, Walking, Standing

    OnStart and OnStop are custom names for triggers, accessible within event sheet. They would act just like any triggers. Walking and Standing are current states, which could be checked in conditions somewhere.

    b) Non-Layout Object. Sometimes a pure FSM is needed to handle more complex transition trees. Some states may not necessarily relate to objects. In this case, transitions and triggers could be accessed globally without having to pick the specific object up.

    Example: FSM Object

    OnGameStart, OnGameOver, OnPause, Paused etc.

    I leave further technicalities to more knowledgeable. There is no doubt, however, of usefulness of such a plugin in Construct projects. It would reduce much of clutter.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Is it in Construct? If so, it better not be something major right off the bat. I'd suggest starting with a barebone prototype to get the feel for Construct and allow for instability and fixes as it comes out of beta.

  • Yeah, I guess people who know Python prefer to develop games with Pygame and stuff, since it gives them more freedom.

    Also, why do I have the feeling of deja vu? I'm sure I've said a similar statement somewhere on these forums...

  • Nooooo! They stole my dog!

  • Sorry, I didn't mean to ask that in an aggressive manner, it just seemed weird that you were asking all those questions. What would you think if someone asked you the same questions? I just wanted to know why you were interested in my name.

    And yes, our people come from the same roots, which is why there are so many similarities between our languages (Dober Dan, Dobri Den etc.) as well as names, though most of names have older origins (Miha is a form of Mihael, which is obviously an ancient name).

    Then again half the Europe is Slavic, so hardly surprising.