oosyrag's Forum Posts

  • You can have as many client input values as you want.

    You can also send messages.

  • Personally when doing inputs, I only use one event for any given key press, like W. Then I use subevents to determine what happens under different conditions when that button is pressed. When you have 'W on pressed' at different levels in different events, conflicts can happen, and will be harder to diagnose.

  • Remove event 8.

    Your object gets stuck when doing two attacks consecutively in the air.

    This is because after the first one, you set velocities to 0, which I believe invalidates both the is falling and is jumping conditions. This makes it trigger event 8 which is w pressed when not on floor, switching to the fumble wham animation. Since the jump attack animation never finishes, event 33 never triggers and gravity never gets enabled again.

  • I'm not familiar with this regarding mobile exports, but there are additional reset actions in the system object that I'm sure would let you get the specific effect you want with little effort.

  • Try saving a copy of your project, deleting everything (or possibly suspect parts) out of it, and seeing if you can export.

    After you using any particularly large project files?

  • Since the card is "face down" it doesn't even need to have a value. You can store the answer in a variable. On start of layout, set variable to int(random(x,y)). You can create your card or animation based on this "correct answer" variable.

    How do you plan on inputting a guess? Does the user have multiple choices to pick from? Do they enter it in a textbox?

  • Try using browser-reload.

  • Make a minimal project with only the problem you are having, other people don't want your whole project either.

    If you can't recreate the problem in a minimal project, you probably just had a mistake in your main project. A lot of times you can find the problem just by taking away everything else.

    You can upload to Dropbox or Google drive or something similar to share.

  • Can't verify without seeing.

    If it's reproducible, file a bug according to the guidelines.

  • Check for typos, and that your layouts are linked to the correct event sheets.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • What have you tried, and what are you stuck on or having problems with?

  • I'm no expert by here are my 2 cents...

    General advice - Always create assets larger than you need for any platform, and reduce their size to whatever is suitable upon exporting in your graphics editor program.

    1. Normally I would target a screen size/resolution of 1080p or so, given that many phones are already capable of such resolutions. Downscaling is acceptable in most cases (additional considerations need to be taken for pixel art), upscaling causes more visual quality degradation. Regarding memory, it depends on the game. I normally want native resolution (1080p) assets, as long as I control the amount of total assets on any given layout. If I were to do an especially asset heavy game, I may have to use lower quality/resolution assets. This is a compromise that depends on your game. Note that none of this actually has nothing to do with the target aspect ratio, which should always be designed to be flexible regardless. Assets don't stretch on a single axis depending on aspect ratio anyway.

    2. You probably don't want to do this. Again, sprite resolution/quality has nothing to do with aspect ratio, so best not to get that confused. You CAN have a high quality/low quality mode, and load in different resolution sprites/textures in your objects. I wouldn't recommend this, as it's a ton of work and generally unnecessary. For example, Flash had an option for low quality mode and high quality mode, that I personally never actually touched and I suspect most other people didn't either.

    3. Yes. The browser object has a condition that detects portrait landscape. You would need to design for two different orientations and use the appropriate one. Otherwise, if you want it to be user selectable (not recommended), you would simply design for each orientation and make your game fixed in that position and have the user rotate the phone to view your game properly (one version vertical, and another one literally sideways).

    Anyways, the main point I think you should avoid getting confused is that resolution and aspect ratio are totally different (albeit related) things. There is no choosing or changing assets resolution based on aspect ratio, you only design for position and what is/isn't visible at different ratios. Assets made for high or low resolution (4k vs 640x480) screens on the other hand, could would matter, even if the aspect ratio was identical. A high resolution sprite made for 4k would be downscaled on a 640x480 screen, but use just as much memory, so memory is wasted, whereas a low resolution sprite made for 640x480 would be upscaled and be visually compromised on a 4k screen. Again, this is something most people don't need to design for. Unless you expect to lack enough memory on your target system (very hard to judge for mobile), use as high resolution assets as you can that is reasonable without overshooting your target.

    Also note that a modern mobile device has significantly more VRAM available than the most excellent supporting multiple screen sizes tutorial, which was written 10 years ago, suggests. Many devices now also allow regular memory to be utilized as video memory, which in effect makes your effective VRAM available not as big a consideration, unless you're doing something really absurd. It's not something I've had to worry about for a long time by just aiming to be efficient in general (large amounts of graphical assets still can take a long time to load into memory at the start of layout, causing a freeze, even if there is enough memory available to hold it all).

    Edit: Upscaling is actually generally quite acceptable as well. Even while some mobile devices have super high resolution now, the physical screen size is still a small space, so a normal eyeball wouldn't be able to visually discern a degradation of quality. Even then, quality is relative to all the other apps out there. For example, if a user was using a cheap, large, tablet, with a low resolution, yes your game might look like shit, but so would every other app the user runs on that device, so they're probably used to it.

    TLDR: Aside from designing for multiple ratios, which has nothing to do with asset quality, it is probably better to focus on making your game more fun than worrying about things like multiple quality settings.

  • Recommend using a function to spawn enemies. The parameters would be type and number of entities.

    You could use a project file if you want to make a long list of what to spawn at each level. This could be xml or json. You can use the array editor to save an array as json, and load it at start of layout.

  • You do not have permission to view this post

  • You do not have permission to view this post