oosyrag's Recent Forum Activity

  • There is a image transform, scale x and y in the tiled background properties you might have missed, I think that's what you want.

    Then make the base texture half as large pixel wise, but scale 200%.

  • If you're using families to pick multiple instances of the same object, delete both the picked object and the picked family object to get rid of both.

  • construct.net/en/tutorials/supporting-multiple-screen-17

    The Scale inner fullscreen mode scales up the game to fill the available space, but if the aspect ratio is different, it cuts off parts of the view.

    The Scale outer fullscreen mode works like Scale inner, but if the aspect ratio is different, it shows more of the layout instead.

    You want scale outer, and design your UI for the narrowest aspect ratio but add "extra" screen space for wider aspect ratios.

    Scale outer is generally the most commonly used.

  • The peer will need to let the host know that it wants to do something, either by sending a message with the result, or sending it's input states, and the host can decide what to do about it.

    For example by input state I mean for example if the peer clicked a button on their screen, the peer would sync/send the input states of clicked, and the coordinates where it was clicked. The host would determine what to do/update, based on what it expects to be at those coordinates.

    By message, it would mean for the peer, on clicked button, would send a message to the host saying " I clicked this button" or equivalent, and the host would determine what to do on message received, for that particular message.

  • Input states can only be values, not strings.

    Did you try seeing input states interpolation to angle instead of none?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • If it's repeating anyway, why do you have to have the base texture over the limit? Just scale it down.

  • Are you painting the entire level inside the specified width of a tiled background? That doesn't do anything, the point of a tiled background is that it's supposed to tile and repeat with little to no overhead, so you can have an infinitely wide tiled background as long as the repeating texture is less than 4096.

  • Tiled background is the way to go, and preferred practice. Have you tried reducing the width to 4096 as suggested by Construct?

  • Anything you want handled by the host, should be in the host group. This would normally be most of the game.

  • Does the AI have to play perfectly? If not, then just break down what you would do in any given situation in terms of available information and decision to be made. The key is to really identify why you make the choices you do and translate that into conditions.

    Otherwise, you're gonna need to understand the math behind it or find someone to do it for you.

  • You should do read and follow the multiplayer tutorials.

    You can consider the host to be the "real" game. Syncing refers to updating synced objects' properties (position, angle) on peers to match the host's game state.

    Peers send their inputs to the host via input states or messages, and the host then applies those inputs to the game objects, which are then synced back to peers.

    In a real time game, to hide latency, peers can also apply their inputs to their local copies immediately when pressed by using local input prediction.

    Syncing objects and local input prediction are sometimes not necessary in a turn based game, given that results of inputs are deterministic. That is when the result of any particular input will always be the same on any device. Messages can work fine in this case for peers to communicate with the host either what was input, or the result of what happened after the input (or both). If not using synced objects, the host will then need to forward the same message to all the other peers. Naturally that doesn't apply if there are only 2 players involved.

  • You can have collisions on an animated sprite.

    You don't need them separate.

    I find it is helpful organizationally to separate the underlying collision logic from animations myself. Animations can change shapes, sizes, and origin points which may have an effect on collisions. When dealing with a lot of animation frames or when making changes to animations, it is pretty common to accidentally introduce hard to spot irregularities in regards to bounding boxes.

    Tldr you definitely don't have to, but many people do so as a "best practice".

oosyrag's avatar

oosyrag

Member since 20 Feb, 2013

Twitter
oosyrag has 39 followers

Trophy Case

  • 11-Year Club
  • 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
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • Continuous Visitor Visited Construct.net 365 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

21/44
How to earn trophies