oosyrag's Forum Posts

  • If you want homing bullets, you'll need to set a target for it, and then set the bullet angle of motion towards that target every tick.

    You'll also want some additional instance variables, so that each bullet can "remember" what it's target was.

    Or projecting the trajectory of the target is also an option, but that can get even more messy.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • After narrowing down a target by picking, you can use the action set angle of motion to angle(bullet.x,bullet.y,family.x,family.y), where bullet is the bullet's current location, and family is the x and y of the picked object. The angle() expression gives the angle between the two.

    You can also narrow down the targets by using the "Is on screen" condition before picking a random instance. Note the order is important, conditions filter in order. So if you used pick random instance, and it picked something off screen, and then had "is on screen" afterwards, you would end up with nothing picked.

  • I haven't tried it, but it may have to do with how the multiplayer object updates the position of synced objects. Have you tried just setting the cone's position to player.x/y every tick instead of using the pin behavior?

    Is having clientside objects that only exist for the peer even possible?

    Yes

  • If you have 4 separate sprite objects as "enemies", you would normally put them all into a "enemies" family, and then you can use the system - pick random instance to get a random one. That way you don't have to repeat your events for each enemy object.

  • Firstly you will need to keep track if any given bullet can bounce, or if it should destroy itself. You can do this with an instance variable on the bullet object. Lets call it bounce, and set it to 1 by default.

    On collision with target, add some sub events. You can compare instance variables. If bullet.bounce is 0, destroy bullet. If bullet.bounce is > 0, subtract 1 from bounce, pick a new target based on your conditions, and set bullet angle of motion to angle(bullet.x,bullet.y,target.x,target.y).

  • Add an event: On Start of Layout - Destroy bullet

    Or better yet, add the destroy outside layout behavior to the bullet, and place the first one in the margin outside the layout in your layout editor.

    I recommend following the Beginners Guide to Construct

  • I don't think this is going to work. Importing sprites and project files are done from the local drive.

    The only thing I can think of is for you prepare all the assets for them in a project file ahead of time to have your students work with. This would be good for teaching specific lessons, but not so much for your student to make their own things.

    • How are things going with the timeline editor and tweens? Should we be striving to use these tools for animation instead of the movement behaviors we relied on before the timeline editor was introduced?

      I would say timeline, being an implementation of flash style editing (which was designed to create animations as opposed to games), is definitely suitable for use if your goal is to create an animation. Its always good to note that there are many ways of doing the same thing when it comes to programming, usually each with their own strengths and weaknesses.

      What about the tile movement behavior that was introduced in late 2018? This seems like a great way of avoiding all sorts of collision detection errors.

      Tile movement is great for tile movement. That is if you're looking to move objects in discrete steps, it makes it easier to do. Previous behaviors generally dealt with constant motion over time.

      Collision detection is a separate and heavy subject by itself.

      Have interactive dialogue trees become any easier, or do we still need to engage in JSON acrobatics and third-party tools to make it work smoothly? (Not criticizing C3 for this. Just remembering that this was often the most difficult part when helping students implement their game ideas.)

      Dialogue is complicated, just like menus, in that there are so many ways to implement it depending on what you want and are comfortable with. For example, I never touched JSON for dialogues, I found XML to be more suitable for me.

      Dialogue trees specifically can get out of hand really quickly. If you're teaching a traditional flash style animation class where one of the assignments is to create an animation that the user can interact with and have branching paths, I would recommend just utilizing different layouts for the branches in a choose your own adventure type setup. Change to the appropriate layout/event sheet upon making an interactive choice. This would be a good place to introduce the persist behavior and how the global property/objects work as well.

      For beginners, honestly I would advise against teaching JSON as a format to be directly edited, and instead teach it simply as a kind of a file type that can be saved and loaded conveniently. Construct has actions that take care of converting its various data structures to json, and read them back. Editing them manually 99% of the time just results in headaches and errors.

      Should I now be teaching my students to use function maps from the get-go?

      Probably. Functions are useful tools in any programming language.

      Use case 1: A good way to organize any set of actions they find themselves repeating in their events more than once.

      Use case 2: A set of actions that depend on an input parameter/variable that can change, that is used more than once.

      Use case 3: To create your own custom expressions that you would use more than once.

      The key is that if you're going to use that set of actions repeatedly, its probably a good idea to stick it in a function. Also if you're working with multiple layouts, it can be a good place to introduce how to create dedicated event sheets (in this case for functions) and event sheet includes, which are very important for organizing larger projects. Speaking of larger projects, another huge advantage of functions is that if you want to make a change you only have to change it in one place, rather than in all the events that have the same copy of actions that you might forget to change.

      How are things going in terms of JavaScript integration with C3? When would folks want to code in JS instead of using the C3 visual tools?

      It works. You could use it if you're more comfortable with JavaScript already and its easier for you to just slam out the code. I'd say the main use for it now is interacting with APIs for outside tools that have JavaScript documentation. Or implementing something that Construct doesn't cover, but you are able to find resources outside that describe how to do it in JavaScript. Anyways not something I would go into much in an introductory class.

    • Note that "2d" platform games with huge, nonrepeating assets and levels such as ori and the blind forest and child of light are actually created in a 3d engine, which has different rules. The memory budget for textures is still a thing to consider, but the geometry is drawn during runtime. This allows for basically unlimited shapes to paint textures onto.

      For 2d engines, the common approaches for huge levels are either tilemaps or reusing scaled/stretched/tinted assets. See construct.net/en/blogs/construct-official-blog-1/remember-not-waste-memory-796 for an example.

      As I mentioned before though, Construct 3 allows for the ability to load and unload sprites/textures from memory on demand. This will allow you to basically stream in assets as needed, as long as you clean up any unneeded ones at any given point. This can be difficult to design around, considering the graphics memory capacity of user devices can vary greatly, not to mention a lot of work.

    • Something like this?

      dropbox.com/s/n1nt5yuih8c3exe/Boxes-example.c3p

      For each created box, check if the distance is farther from the origin than the touch distance. If it is, set opacity to an inverse function with x, where x is the distance from touch (as distance increases, opacity decreases, normalized between 0-100).

    • construct.net/en/make-games/releases/beta/r117-2

      Basically you'll be manually loading an unloading your sprites during runtime to keep memory usage reasonable.

      I would not recommended doing this unless you're really confident you know what you're doing.

    • You do not have permission to view this post

    • showcase.api.linx.twenty57.net/UnixTime/tounix

      The above is an online unix timestamp you can reference. You can get it via the AJAX object's request url action.

    • If you really want to refactor your actions, you can set x/y offset instance variables for each piece, then loop through each piece to set their position based on their instance variable.