BluePhaze's Forum Posts

  • Hello All,

    As part of my ongoing development on my upcoming game I am trying to work out some touch controls. The game is a platformer and has the following features that will require some type of UI touchscreen control scheme:

    Basic Platform Movement (Left, Right, Jump)

    Fall Through (Press Down to fall through jumpthrough platforms)

    Run

    Double Jump

    Wall Jump

    Change Form (There are three different modes/forms the character learns during the game)

    Action/Attack

    Most of this is for the most part easy to do, the issue I am running into here is really on implementing the run option. When using the keyboard I simply assign a button down event to double the maxSpeed of the character and change the animation to the Run animation. However, I am finding it harder to do with a touchscreen control setup. I do not want the player to have to hold down multiple buttons as that is very difficult on a touchscreen game. My thoughts are to do one of the following:

    1. Implement a double tap on the left/right movement buttons that starts the run. (I am trying to find a good way to do this using a state variable and a timer).

    2. Implement a toggle button on the screen that if it is pressed while moving it will double the walk speed and change to the run animation. This one has been a bit difficult.

    The difficulty in both of these seems to stem from having to use the on touch simulate platform left/right events to get the initial movement working. I believe this is overriding everything else. What I tried at this point is having a global variable called "running". Normally this is set to 0. If they touch the run button while they are walking (Holding the left/right touchscreen buttons) it should set the walk speed and animation accordingly however this does not ever seem to work.

    My assumption is that since the touch left/right button events are written as "Is Touching button > Simulate Platform Pressing Right" that it is overriding anything else I try to do to the movement. Below are some of the various schemes I have tried while working on this, none of them seem to do what I want.

    The base movement updated with touch events and keying off the running variable:

    <img src="http://dl.dropboxusercontent.com/u/10285716/ConstructSampleScreenshots/MovementTouchUpdate.png" border="0" />

    The touch events

    <img src="http://dl.dropboxusercontent.com/u/10285716/ConstructSampleScreenshots/PlatformTouchEvents1.png" border="0" />

    And Another option trying to detect when they let go of the left/right buttons to deactivate the run:

    <img src="http://dl.dropboxusercontent.com/u/10285716/ConstructSampleScreenshots/DetectReleaseOfTouch.png" border="0" />

    ALso here the updated double jump logic to take touch into account as well, this works just fine it is just to illustrate how I am integrating keyboard and touch into the same project:

    <img src="http://dl.dropboxusercontent.com/u/10285716/ConstructSampleScreenshots/TouchDoubleJumpLogic.png" border="0" />

    The jumping, double jumping and even the wall jumping all work as expected with touch, but the run does not work at all. Once in awhile I will see the character start the first frame of the run animation when the run button is touched while walking, but that is as far as it goes. It reverts right back to regular speed and walk animation. The various variables used in the events are pretty self explanatory based on their names, but if anyone needs clarification just let me know.

    Thanks,

    James

  • You could also just use something like Spriter to do this as it is free currently. You take the sprite pieces, then import them to create the animations with all the pieces.

  • spongehammer Nice, have you had any issues with it in terms of stuttering or jitters when you play fullscreen on different devices or computers?on different devices or computers?

  • Hello All,

    I am currently working on a platformer with a focus on exploration sort of like a metroidvania style. I have been experimenting with different ways of implementing scrolling to try and make it a smooth process across different devices and computers. I am looking to see if anyone has done any testing around different camera/scrollTo methods that you have found give the most consistent results. Below are the options I have tried and most of them seem to introduce varying degrees of background stutter depending on what device they run on:

    1. Simple applying the ScrollTo behavior to the character object. This works great but shows way too much below the character. You have to create really large sections for flooring, etc... if you don't want the player to see what is below them This is mainly due to the character being centered on the screen when scrollTo is applied to them.

    2. Pinning a "Camera Sprite" to a position above the character. The Camera sprite would then have the scrollTo behavior applied to it. This seems to introduce a good amount of stuttering randomly. Especially when parallax is used for background layers.

    3. Using events to position the camera sprite above the player, and then using the Scroll To action to scroll to the camera sprite. This is all of course done every tick. This seems somewhat smoother than the above option, but when testing on other computers it seems to introduce random stuttering of the background.

    Has anyone played around with the above options or found another option that works better? My goal is to have the scrolling of the layers as smooth as possible and also allow for some flexibility as to where the focus of the scroll is. What I have found so far is the best position seems to be about 150 - 200 pixels above the character. Combining this with adjusting the jump strength helps to ensure they can't see too much below themselves, but can still see the ground when they jump.

    I am open to any better ways of implementing the scroll to/camera behavior to allow for control and smoothness. I have multiple layers though only about 2 or 3 of them have parallax applied to give varying degrees of depth. All other layers are either at 100,100 or at 0,0 for the HUD.

    Thanks!

  • Tutorials, Manual, etc... the normal stuff. No matter what type of game you want to make, the first step is getting good with the tools. Welcome to the community!

  • alexwdara without seeing your logic/events it is hard to guess but I would say you need to add a for each condition above the logic that turns the bullets.

  • Nimtrix yeah, my background is as a developer so I am just used to going that route first. Though if you did it based on a percentage of the window like the halfway point, etc... then it would work across multiple resolutions as well. Not sure if the overhead of an extra calculation would offset the extra object or not though resource wise.

  • Nimtrix Right, that should fix it according to the documentation. Another way would be to use variables and base it off of the viewport or window as they are rectangles you may be able to just use the size to figure out where to tile it, etc... though that may get complicated if you are publishing to multiple sizes. Basically calculate where the tiles should begin instead of sticking them to another invisible sprite.

  • One thing to also check if you look at Construct Dudes videos on youtube is that he has one where he talks about publishing an MS Market game and which countries to leave out if you want it to go through quicker.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Nimtrix For VRAM yes, because VRam is based on how many pixels of the screen are being rendered, not on the size of the file/object in memory. So a 1 pixel .png stretched across the whole screen will use very little system memory but still the whole screen worth of video memory unfortunately. If you stretch a 1px image across the whole visible screen, you are stretching it across however many pixels the screen resolution is using and it has to hold the color value for each pixel on the screen in memory. Kind of sucks.

    I am currently working on a game for both Windows 8 and Windows Phone 8 so am having to juggle constantly if I want to keep both versions as similar as possible.

  • You can also use the preserve option to keep the state of objects in a layout so they remain how they were when you return to that layout.

  • The size of the object is different than the amount of video memory that is used. On a mobile platform you get overdraw if you render more than about 3 time the number of pixels on the screen. This is true regardless of the actual size of the graphic. This is about how many of the pixels on the screen are being drawn and how many times per tick.

    A one pixel tiled image, still uses all the pixels of the screen if you tile it across the whole thing, so while the object itself uses hardly any memory, your video memory is using a lot as it is storying the value of each pixel rendered. Overlapping this with another object increases the video overhead for rendering the screen.

    So regardless of tiled vs. sprites, the video memory is based on pixels rendered, not on the size of the object being used to draw them. Two different areas of memory.

    You can refer to the following threads for more info, also here is a quote on the mobile overdraw issue:

    Mobile overdraw

    While we're on the subject of mobile limitations, it's worth mentioning some mobile devices can only draw each pixels 3 times per frame and still reach 60 FPS. In other words, if you have four window-sized images on screen, you cannot reach 60 FPS on such a device. (Note Construct 2 renders scenes from the back to the front, so four overlapping objects are all still rendered.) Perhaps surprisingly, this includes transparent pixels. The GPU processes the full rectangle of a texture regardless of the content, and a transparent pixel still uses up your drawing budget, so four window-sized transparent images would still not reach 60 FPS. Similarly with memory usage, this is a device hardware limitation and you'll have the same limitation with any framework.

    The solution here is again to prefer using small images instead of large ones. A large image will eat up lots of the mobile's drawing budget in one go, whereas it's easier for it to render several spread out smaller objects. For example, a window-sized sprite to add borders round the edge of the screen is very inefficient, since the transparent pixels in the middle still use up the draw budget; using four separate sprites for each edge of the screen would be a lot faster.

    You can find more about properly composing your backgrounds here:

    The "Right" Way to do backgrounds in C2

    And Ashley's blog post where the quote was taken from:

    Remember not to waste your memory

  • For the actual drawing of the sprites I use Adobe Illustrator (CS6, CC), Inkscape (Free), and once in a great while if really needed I use Adobe Photoshop or GIMP (Free). However lately Illustrator has become my main tool. And I have also found that if I take my work in illustrator (depending on the type of graphics being done) opening them in Adobe Fireworks and Exporting the PNG from there can save more room as well. Fireworks seems to have some better PNG compression than some of the other tools.

    For actual animation of my sprites I use Spriter. You need to know that Spriter is not for drawing your characters. You draw their parts in another app like illustrator, then save them as separate files and then import them into spriter and put them together and animate them. You then have the option based on your preferences to export the animation frames as PNG files which can be imported as frames into C2, or export the whole animation as an .scml file which C2 can support using the Spriter plugin.

  • Nimtrix doesn't that mean you are also now using double the amount of pixels to do the same thing as the tiled background and the sprites both overlap eachother and even if transparent it still gets it's pixels rendered. Maybe not an issue on some platforms, but if you look to go mobile that could quickly cause performance issues. Just a thought...

  • Just a side note, please give more descriptive titles/subject lines to your posts. Not many people see a post called doubt and want to read it. If you called it falling blocks with physics, you would get a lot more people looking at this.