Ashley's Recent Forum Activity

  • Woops, knew I forgot something important. I'll push out a 32.2 later to fix.

  • Download Construct 2 public preview 32.2

    Link to release 31

    This build, with several other changes, introduces the behaviors engine. There is only one working behavior - 8 direction - which is there mainly to prove the engine works. There's plenty to do still, but this should give you something to try out, as well as a few other tweaks, and r31 is due to expire soon anyways

    Edit: updated to 32.2 to fix broken input plugins.

    Changelog

    • [Feature] Early implementation of behaviors. The behaviors dialog is modelled after the instance variables dialog, where behaviors can be added, reordered and deleted. Attributes have been merged in to behaviors (so 'solid' is now a behavior). There is only a primitive version of the 8 direction behavior - there are no behavior actions, conditions and expressions, properties or customisable controls, and 'solids' have no effect yet - it's mostly under-the-hood work to get it to basic functionality.
    • [Add] Can drag-and-drop .capx and .caproj files in to the Construct 2 window to open them.
    • [Add/fix] Can drag-and-drop PNG and BMP files from Windows Explorer in to a layout, and it automatically creates a new Sprite object with that texture. Could be a nice time saver when you have a lot of artwork, especially while there's no picture editor. (Previously this resulted in a check failure.)
    • [Add] 'Add blank sub-event' to right-click menu of events
    • [Add] Project bar and object bar right-click menus have options to edit instance variables and behaviors of object types
    • [Change] New About box
    • [Change] System expression 'dt' (delta time): previously was fixed at 0.016. Now the genuine delta time is measured. This requires a high-resolution timer in the browser. There is conflicting information on the web about this, but from my own tests it appears most modern browsers do have high resolution timing in javascript. If they don't, they might report a delta-time of zero. If so, the runtime will detect this and fall back to a fixed value of dt like before (0.016). Let me know how this works out and if there is any choppy motion using dt in your movement calculations (or in behaviors which always use delta time).
    • [Change] Selecting an object type from the project or object bar shows properties as if all its instances in the project were mass-selected. This is probably much more useful when working in the event sheet editor.
    • [Change] Object names (and behaviors) are now allowed to start with numbers as long as there are non-number characters in its name. In other words, names like "8Direction" or "3DObject" were previously not allowed, but are OK now.
    • [Change] Preview in browser has a centred canvas and dark background.
    • [Fix] Creating an object on a layer by number chooses the nearest layer if it doesn't exist (e.g. creating an object on layer 1 with a single layer, 0-based, now creates the object on layer 0 instead of doing nothing)

  • Oops, sorry, got mixed up

  • Sorry, I guess my other post was a bit critical for someone without much coding experience. It's cool that you're thinking through ideas like this, but there are still a few problems:

    • you can't assume all your players have a ramdisk (or SSD) - the reality is most people have traditional hard drives
    • writing files is probably quite slow, again because it's not designed for latency - complex games might take a framerate hit
    • the overhead of writing files is still large, so although your simple case works, you might find you can't add many players or much more data in transmission before it bottlenecks. It's not so much the maximum data rate as the latency that is the problem (i.e. how long it takes the message to arrive, rather than how much data the message holds).

    I think R0J0 did some python tutorials on how to use sockets? You might be able to search the forum for that. Also, you could try reading up on websockets - that's what modern browser games use for multiplayer.

  • This isn't a good way to design a multiplayer game! You shouldn't use files on disk (you're moving the mechanical drive head when you could be reading directly from memory), and using files or HTTP is the wrong protocol. These systems are designed for one-off transmissions: open connection, transmit data, close connection. You're introducing a huge amount of open-close overhead for every single message. Also, these protocols are designed for file transmission, where latency really isn't a big deal. They are only concerned with eventually getting the data there, rather than working in real-time. There's also no message ordering so you can get your data reordered in transmission and your players start jumping all over the place. The right way really is to open a socket connection and stream data. That solves all these problems, and was designed for such purposes.

  • Yes, the javascript in Construct 2's HTML5 runtime can do anything it can on a webpage, like XMLHttpRequest. Also, HTML5 adds websockets which can do realtime server-client communication.

  • I think the error message will be fixed in the next build, but what picture editor is brought up by Construct? It's the default system PNG file editor, so if that program doesn't save over the temporary file C2 creates, it won't save the texture and you'll just get a transparent square.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Yes, you should be able to enable and disable behaviors in families, as well as on a per-instance basis. As with attributes they will appear in object pickers so you can do the for-each you proposed.

  • DtrQ: no, you'll just add a 'solid behavior' to it, not a platform movement, they're different things. I don't see any reason it'll reduce performance either.

    Having a 'solid family' is a good idea, but I think everyone's forgetting a limitation on families: due to the way family events work, you can only have one plugin type in a family (e.g. all sprites, all tiled backgrounds, all text objects). So if this limitation is kept, you can only make either sprites or tiled backgrounds solid - not both! If this limitation is removed then there's a big question about what happens with the events. I'm also not sure what effect it would have on the runtime, which in many places assumes there's a single plugin type in a family.

    Something else to consider is we're planning a new model for families when we get round to them. Objects will inherit the variables and behaviors from the families they're in. So instead of family variables and behaviors being all-those-in-common, you define them seperately and all objects in the family get them, no questions asked. In this case, you can add a 'Sprite solids' family with a solid behavior, and any object in that family also gets the solid behavior. This way you get both! You can make an object solid either by adding the behavior, or adding to a family you made with a solid behavior.

    With that in mind, does this sound better?

  • Well, I think you could argue all behaviors could be a list of checkboxes that you tick as well. It's not what you're used to, but I think it still makes a lot of sense - an object behaves as a solid, so it has a solid behavior.

  • What's still kind of limiting about it? How is adding it as a behavior more limiting than ticking a checkbox?

  • Hey everyone,

    As I was working on behaviors for the next build, I had an idea. Previously in 0.x attributes have been added as a series of predefined checkboxes in the properties, such as 'solid' and 'centre view on me'.

    It seems to me kind of pointless having a separate set of checkboxes for this. I think a better way is simply to merge them all in to behaviors. In other words, to make an object solid, you'd add the Solid behavior to it.

    IMO this simplifies the editor - there's no distinction between behaviors and attributes - and this is simpler to write as well. (No need to program attributes as a separate thing.) It also could add some flexibility - if you can enable and disable behaviors at runtime, you can enable and disable attributes like solid.

    The only thing I can think of that's lost is user-defined attributes. However, families (when they get done) pretty much substitute them completely.

    This seems like a pretty good thing to do to me, but I thought I would check and run a quick poll to see what people think. I like polls anyway If you have any suggestions or variations on this which you think would be good, do mention it in a reply!

Ashley's avatar

Ashley

Early Adopter

Member since 21 May, 2007

Twitter
Ashley has 1,769,849 followers

Connect with Ashley

Trophy Case

  • Jupiter Mission Supports Gordon's mission to Jupiter
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Forum Wizard Made 5,000 posts in the forums
  • Forum Unicorn Made 10,000 posts in the forums
  • Forum Mega Brain Made 20,000 posts in the forums
  • x126
    Coach One of your tutorials has over 1,000 readers
  • x74
    Educator One of your tutorials has over 10,000 readers
  • x5
    Teacher One of your tutorials has over 100,000 readers
  • Sensei One of your tutorials has over 1,000,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x42
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

32/44
How to earn trophies

Blogs