Ashley's Forum Posts

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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.

  • 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!

  • If you need general javascript help it might be better to try a dedicated programming forum or a site like Stackoverflow.

    MDC is also an excellent reference for javascript - check out the doc for Math.abs().

  • Didn't I add an anglelerp expression a few builds ago? I can't check right now, my laptop's broken!

  • We could eventually make a WebGL exporter - it just won't run on IE, which will make it a lot less useful for real-world use.

  • Formula Input information:

    Have you tried the latest build? Try typing lerp(. You get exactly what you describe.

    [quote:2sj4vkn6]New Blank Subevent:

    Added for the next build.

  • Arima's right, Windows doesn't really support window controls in fullscreen DirectX apps. Sprite button is the better choice.

  • You could join the Scirra Facebook group here: http://www.facebook.com/ScirraOfficial