Tuesday, June 28, 2016

Unity 2d Physics Tutorial - More Materials and Playtime Bouncing and Sli...



unity 2d physics tutorial, unity tutorial, unity 2d physics game tutorial, game engine, unity 2d car physics tutorial, game design, 2d physics, android (operating system), unity 2d physics tutorial, make a platformer, unity (software), platform game (video game genre), unity (game engine), unity2d, unity 2d physics tutorial, physics2d, unity 4.3 2d physics tutorial, unity touch input, unity3d 2d car physics tutorial

Friday, June 17, 2016

Construct 2 Tutorial - 36 Making Touch Controls - Construct 2 Touch Cont...



These days it's naïve to assume everyone on the web has a mouse and keyboard. On the modern web, many people are now browsing via touchscreen devices
like iPhone, iPad and Android phones. If your game can only be
controlled by mouse and/or keyboard, users on these devices will be unable to play your game!

However,
it's easy to have on-screen touch controls - and there's a clever and
simple trick to detect whether the user has a touchscreen device, too.

Mouse input for touch

First
of all, if you're designing a game specifically for touchscreen
devices, or your game only uses mouse clicks, use the Touch object. Set
its Use mouse input property to Yes (it's No by default). Now mouse clicks fire touch events like On touch start and Is in touch.
Obviously you can only simulate single-touch input by mouse clicks -
holding the left button down represents touching, and releasing it
represents not touching. So a click-and-drag represents a swipe by
touch.

That easily allows for both mouse and touch input, which for simple games is enough on its own.

On-screen touch controls

For many other games, on-screen buttons are necessary for controls. These can be made with Sprite objects.

First,
if you don't have one already, make a non-scrolling layer (you don't
want the buttons to move off the screen as you scroll through the
level!). Add a new layer and set its Parallax to 0, 0. This prevents any objects on that layer from scrolling - they'll always appear in the same place on-screen.

Now,
make sure that layer is selected. The dotted outline in the top-left
of the layout view shows the size of the window. Add some Sprites
representing your on-screen controls somewhere within the window area.
An example of on-screen arrow keys in the bottom-right corner of the
window is shown below.

Touch controls
Remember
big buttons are easier to touch! You may also want to tweak the
collision polygons in the image editor to make their area slightly
bigger and therefore easier to touch.

Now you can use the Touch object's Is touching object actions to call a behavior's Simulate control action, such as below:

Touch control event
Now you have on-screen controls that always stay the same place in the window and can control the game.

If
your game uses simple left-right controls you can use variations, like
large invisible sprites to detect if the user is touching either the
left side or the right side of the screen. Remember, the bigger the
area they can touch, the easier it is to control the game.

Alternative touch controls

There
are lots of different ways to control games on touchscreen devices.
You don't have to have on-screen controls, and sometimes alternatives
are easier and more fun to use. Here are two other suggestions:

1.
Touch around the player to move them, instead of having on-screen arrow
keys. For example, in Space Blaster, the space ship could move to
wherever you are currently touching. Other buttons on screen can then
give alternative actions, like firing rockets.

2. Use the device accelerometer to control movement. In the Touch object, you can retrieve these as the Alpha, Beta and Gamma expressions. This allows you to detect the device tilt along different axes, which can then drive some movement.

Finally,
you may wish to adapt controls to be easier for touch devices. Touch
controls can be more difficult to use than a keyboard and mouse, so
simplifying the controls can make the game more fun. For example, the
player most hold spacebar to fire the main laser in Space Blaster.
Changing the laser to automatically fire while enemies are on-screen
made the game more fun than having to press a separate 'fire' button.
It also makes it a little easier, but surely the main aim is to make it
fun and not frustrating to control!

Detecting input method

So
now you have on-screen touch controls. What if the user is on a
desktop computer with a mouse and keyboard? There's no point showing
big on-screen buttons in that case. Fortunately, there's a really
simple way to detect if the user is using touch input: have a title
screen.

It's really that simple. On the title screen, have a message like Press anything to continue. Then, if Keyboard's On any key pressed or Mouse's On any click event fires on the title screen, you know the user is on a desktop. If Touch's On touch start
event fires on the title screen, you know the user is on a touchscreen
device. You can then set a global variable indicating if the user is on
a touchscreen and proceed to the first level. If the global variable
is set, show the on-screen touch controls; otherwise, make them
invisible. You'll automatically be using the right control system, and
the user did not have to do anything!

That's all there is to it!

Construct 2 Tutorial - 35 Scaling and Sizing - Supporting Multiple Scree...

Virtually every game has to work on a different sized
screen. This can be different size phone screens - which can even vary
across different versions of the same device, like the iPhone 4S vs.
iPhone 5 - different size tablet screens, resized browser windows,
monitor resolutions, and so on. Even fixed-size games running embedded
in a page can switch in to fullscreen mode, which means they still need
to support different size displays.

This means almost every
game should have a way to support multiple screen sizes, whether
intended for desktop or mobile. This tutorial will cover the basics of
supporting multiple screen sizes.

The short version: don't target one resolution

A
common misconception is that you need to target a specific resolution,
like 1280x720. However, there are so many different resolutions used
that it's ridiculous to pick just one. It's much better to pick an aspect ratio, then scale
the game to fit that. For example, instead of 1280x720, target the 16:9
aspect ratio. (Just enter any 16:9 resolution for the window size in
Project Properties.) Enable Letterbox scale in the Fullscreen-in-browser project property, and now your game should appear correctly on any
16:9 resolution. If the display is not 16:9 then black bars appear down
the sides, which helps prevent unintended display issues like
accidentally seeing too much of the level or menu screen. Note if you
are designing a pixellated retro-style game, you may want to use Letterbox integer scale instead.

The
rest of this tutorial will cover the tools available to you in more
detail. It's still worth reading even if you use the quick solution
above. You can even support different aspect ratios if you are willing
to design your game more carefully.

Using a fullscreen mode

In Project Properties, set one of the Fullscreen in Browser modes.

With this mode set to Off, the game appears embedded within a HTML page at the size given by Window size. However, it won't support any different size screens. If you use the Browser object's Request fullscreen action, you'll still need to support different screen sizes anyway.

Crop mode

In
crop mode the view stays at the same scale, and simply shows more or
less of the layout depending on the window size. The images below shows
a small window in crop mode. The player appears the same size, but
there is less of the layout visible.

Fullscreen in crop mode.
If
the window is resized larger, much more of the layout can be seen.
Notice how now the window is larger, the player can spot the monsters
further away.

Fullscreen in crop mode.


This
mode allows you to control scaling yourself, or simply ignore scaling.
However, this mode is generally not good for games. Consider the
iPhone and iPad which have the same physical size screen, but at
different resolutions depending on the generation. Since Crop mode
doesn't do any scaling, it can make your game look strangely small on
high resolution devices.

Letterbox scale mode

Letterbox scale
mode simply scales the game to fit the window. If the aspect ratio
does not match, black bars appear down the sides of the window. Here
are two examples:

Letterbox scale example 1
Letterbox scale example 2
Since
black bars appear down the side, it avoids the problem of accidentally
showing content that's supposed to be offscreen. However, the
disadvantage is that some users lose some of their viewing area to the
black bars. Despite this, Letterbox scale mode can be applied
to almost any game and have it still work correctly, so is a quick and
easy way to support different screen sizes without having to alter it
for different aspect ratios.

Letterbox integer scale

Letterbox integer scale mode is identical to Letterbox scale
mode, preserving the aspect ratio, but it also only zooms to an integer
scale. For example it will only scale at 1x, 2x, 3x, 4x etc. and never
at something like 2.5x. This is important for games using Point
sampling (usually retro style) to preserve exact pixel-perfect accuracy
when scaling the game. This also means black bars can appear at both
the sides and top and bottom.

Letterbox integer scale example 1
Letterbox integer scale example 2


Scale outer mode

Scale outer mode scales the view to fit the window size, just like Letterbox fullscreen
does. However, instead of showing black bars, it uses the full display
and shows more of the layout. This has the side-effect of sometimes displaying more of the layout than the window size.
This can mean empty space or supposedly off-screen objects can appear
down the sides of the screen if you don't design your game accordingly.

Notice how the game is scaled down with a small window, without showing black bars:

Fullscreen in scaling mode.
However if the window is resized to an unusual size, the game displays incorrectly:

Scale mode with bad aspect ratio.
The
game has scaled appropriately, but the aspect ratio is so wildly
different that you can see past the right edge of the layout. Not only
that but the player can already see some monsters they couldn't see
before, so this might count as cheating. With Letterbox fullscreen this would have been covered up by the black bars, which is why it's often preferable to use letterbox mode.

However
if you are targeting specific devices with non-resizable windows, you
can use this mode to support different aspect ratios. But the problem
above still applies; you will need to do things like draw backgrounds
bigger than the window size to ensure empty space doesn't appear on
certain displays, and thoroughly test the game to ensure nothing
unintentional occurs with the game's appearance.

For more information, see the section A common gotcha - aspect ratios below.

Scale inner mode

Like Scale outer, this mode scales the view and uses the full display. However it handles aspect ratios differently: whereas Scale outer shows more of the layout if the aspect ratio is different, Scale inner shows less.
Since it prefers to cut off parts of the view, it never accidentally
shows content outside the window... but you still have the opposite
problem - it might cut off something that you want to be seen!

Here's an example where the game displays correctly when scaled down evenly:

Scale Inner mode
If
we use the same unusual size that we did with 'Scale outer', notice how
it zooms in and cuts off parts of the view instead of showing us too
much:

Scale Inner mode
This is a better result than Scale outer,
but now we need to be aware of parts of the game being cut off on some
window sizes. The above view is like only seeing a narrow bar across the
game's window size. One technique this is useful for is designing games
for the 16:9 aspect ratio, but having the sides cut off when viewed in
4:3. Some movie producers do this with films.

A common gotcha - aspect ratios

Letterbox scale or Letterbox integer scale
are easy ways to get your game to work on a wide range of screen sizes
without having to do much work. However, the disadvantage is that black
bars appear. This can be annoying for mobile users who have a small
screen already, and don't want their display size to be any smaller than
necessary. Additionally, it can look unprofessional if a device's
aspect ratio is only slightly different to the game's aspect ratio -
thin black bars will appear down the sides, which appear to be
unnecessary - the user might wonder "why wasn't the display simply
extended to show the full area?"

Thin black bars in letterbox mode.
In order to support this case with a full display, you need to use Scale outer or Scale inner mode instead of Letterbox scale mode. This then means you need to support multiple aspect ratios as well.

This
is the same problem faced by TV producers. There are many TVs out
there using aspect ratios of 4:3, 16:9 and 16:10. If a producer films a
TV show only in 4:3, on a 16:9 TV there will be gaps at the sides, or
possibly even unintended off-set equipment and crew visible! Similarly,
if you draw a background exactly fitting one display, then run it with Scale outer
mode on another display with a slightly different aspect ratio, gaps
will appear at the side or content outside the layout becomes visible.
This can even happen if you simply don't take in to account the space
taken up by the status bar on devices like the iPhone.

There are two ways to solve this problem:
1) Use Scale outer mode, and draw your backgrounds wider (or taller, depending on orientation) than the window size, past the normally viewable edges, to ensure no gaps ever appear regardless of the device aspect ratio.
2) Use Scale inner mode, and make sure nothing important is close to the edges, since the edges are susceptible to being cut off on different size displays.

It's
not always easy to design a game correctly using either technique.
However it allows you to design games that always use the full display,
which often looks better than showing black bars.





Construct 2 Tutorial - 34 Creating Menu - Construct 2 Menu Tutorial - Ho...

Sunday, June 12, 2016

Construct 2 Tutorial - 32 More Gravity #1- Advenced Player Environment I...



https://youtu.be/RdqrRydib-A
Construct 2 includes the Physics behavior, powered by Box2DWeb. This allows you to have objects moving with real-world physics - here's a demo to show the idea. Physics can make your games really fun and engaging! Here's an overview of how you can get Physics to work in your game.

If you ever took a Physics class in school, you'll find some of the things you learned applicable to Construct 2's Physics. I'll still explain the basics in brief in case you haven't learnt the concepts before. Interested in some of the theory? You might want to read Wikipedia's article on Newton's laws of motion. Here's another link you might find useful.

Lots of physics examples come with Construct 2! Click Browse all examples on the start screen, and all the physics demos filenames start with "Physics - ", e.g. "Physics - basics.capx". They're well worth having a look. The descriptions here will probably make a lot more sense if you've seen it in action first.
How to add Physics

Select an object you want to add Physics to. In the Properties Bar, click Add / Edit under Behaviors. Click the green plus icon and from the dialog pick Physics. All done!

We'll call any object with the Physics behavior added a "physics object".
Gravity

By default, gravity is present on physics objects, which accelerates all objects downwards. The default gravity is 10 (remember, the Y axis increases downwards in Construct 2). If you want to turn off gravity, you can use the Set gravity action on any physics object. Note: gravity applies to the whole "world". If you set gravity to 0 on one object, gravity is turned off for all objects.

General physics tips
Performance

Physics simulations are very CPU intensive. It can take a lot of processing to work out the proper motion. To make sure your game runs fast, it's recommended that you don't use too many objects at once. Over 100 physics objects moving at once is likely to slow your game down. Also, phones and tablets have much more limited processing power than a desktop computer. If you're targeting mobiles, you should be very conservative, and try not to have more than 20-30 physics objects.

Note that objects which have come completely to a stop, and are not moving or rotating at all, are "put to sleep" by the simulation. Then, they don't need processing any more. If the object is hit by another one it "wakes up" and starts using processing again. However, if the object is even moving in the slightest, it won't be put to sleep. For example, all the blocks in a teetering tower will remain awake. It's just something useful to bear in mind for performance: if you have hundreds of objects asleep and at most only ever 20-30 moving (even slightly), the game should still run well.
Stability

Physics simulations are not totally robust. If you simulate unrealistic things, like a gigantic concrete object hitting a block of foam at the speed of sound, the result is likely not to be realistic either. In fact, anything involving extreme forces is likely to cause the simulation to become unstable (unrealistic, e.g. objects moving through or inside each other).

Things like incredibly heavy objects piled on a stack of really light boxes, huge piles of objects, or very fast moving heavy objects tend to cause instability. Try to keep everything in your game at reasonable proportions.

The same also applies to object sizes. Very small (under 5 pixels) or very large (over 500 pixels) objects may not simulate realistically either. Try to keep all widths and heights in the 5-500 pixel range, and still avoid extreme proportions (e.g. a 5x500 sized object).

In other words, Physics will work best with objects of about the same size and mass interacting at relatively low speeds.
Manual movement & other behaviors

If you move objects by events (e.g. set X, set Y) or other behaviors (e.g. also adding 8 direction to a physics object), the physics simulation will do its best to keep up with what you've done. However, it is usually more realistic to achieve the same thing by applying forces and impulses to physics objects. This keeps everything "in the physics world" and realistic.

construct 2 tutorial | construct 2 gravity | construct 2 physics tutorial | construct 2 physics | construct 2 physics platformer | construct 2 course