• # Learning How to write a 2D UFO game using the Orx Portable Game Engine - Part 3

General and Gameplay Programming

# Collisions

This is part 3 of a series on creating a game with the Orx Portable Game Engine. Part 1 is here, and Part 2 is here.

There is one last requirement for the collision to occur: we need to tell the physics system, who can collide with who.

This is done with flags and masks.

Make a change to the ufo's body part by adding SelfFlags and CheckMask:

[UfoBodyPart]
Type      = sphere
Solid     = true
SelfFlags = ufo
CheckMask = wall

SelfFlags is the label you assign to one object, and CheckMask is the list of labels that your object can collide with.

These labels don't have to match the names you give objects, however it will help you stay clean and organised.

So in the config above, we are saying: the UfoBodyPart is a “ufo” and it is expected to collide with any bodypart marked as a “wall”.

But we haven't done that yet, so let's do it now. We will only need to add it to the WallTopPart:

[WallTopPart]
Type        = box
Solid       = true
SelfFlags   = wall
TopLeft     = (-400, -300, 0)
BottomRight = (400, -260, 0)

Remember, that the other three wall parts inherit the values from WallTopPart. So each now carries the label of “wall” and they will collide with any other body part that carries the label of “ufo”.

Re-run and press the left arrow key and drive the ufo into the left wall. It collides! And it stops.

Now that the collision is working, we can flesh out the rest of the keyboard controls and test all four walls:

void orxFASTCALL Update(const orxCLOCK_INFO *_pstClockInfo, void *_pContext)
{
if (ufo) {

const orxFLOAT FORCE = 0.8;

orxVECTOR rightForce = { FORCE, 0, 0 };
orxVECTOR leftForce = { -FORCE, 0, 0 };
orxVECTOR upForce = { 0, -FORCE, 0 };
orxVECTOR downForce = { 0, FORCE, 0 };

if (orxInput_IsActive("GoLeft")) {
orxObject_ApplyForce(ufo, &leftForce, orxNULL);
}
if (orxInput_IsActive("GoRight")) {
orxObject_ApplyForce(ufo, &rightForce, orxNULL);
}
if (orxInput_IsActive("GoUp")) {
orxObject_ApplyForce(ufo, &upForce, orxNULL);
}
if (orxInput_IsActive("GoDown")) {
orxObject_ApplyForce(ufo, &downForce, orxNULL);
}
}
}

Now is a good time to turn off the physics debug as we did earlier on.

Compile and run.

Try all four keys, and you should be able to move the ufo around the screen. The ufo can also collide with each wall.

The ufo is a little boring in the way that it doesn't spin when colliding with a wall.

We need to ensure the UfoBody is not using fixed rotation. While this value defaults to false when not supplied, it will make things more readable if we explicitly set it:

[UfoBody]
Dynamic       = true
PartList      = UfoBodyPart
FixedRotation = false

The active ingredient here is to ensure that both the wall bodypart and the ufo bodypart both have a little friction applied. This way when they collide, they will drag against each other and produce some spin:

[UfoBodyPart]
Type = sphere
Solid = true
SelfFlags = ufo
Friction = 1.2

[WallTopPart]
Type = box
Solid = true
SelfFlags = wall
TopLeft = (-400, -300, 0)
BottomRight = (400, -260, 0)
Friction = 1.2

Re-run that and give it a try. Run against a wall on angle to get some spin on the ufo.

The next thing to notice is that both the movement of the ufo and the spin never slow down. There is no friction to slow those down.

We'll deal with the spin first. By adding some AngularDamping on the UfoBody, the spin will slow down over time:

[UfoBody]
Dynamic        = true
PartList       = UfoBodyPart
AngularDamping = 2
FixedRotation  = false

Re-run and check the spin. The ufo should be slowing down after leaving the wall.

Now for the damping on the movement. That can be done with LinearDamping on the UfoBody:

[UfoBody]
Dynamic        = true
PartList       = UfoBodyPart
AngularDamping = 2
FixedRotation  = false
LinearDamping  = 5

Re-run and the speed will slow down after releasing the arrow keys. But it's slower overall as well. Not 100% what we want.

You can increase the FORCE value in code (ufo.cpp), in the Update function to compensate:

const orxFLOAT FORCE = 1.8;

Compile and run. The speed should be more what we expect.

It would be nice for the ufo to be already spinning a little when the game starts. For this, add a little AngularVelocity :

[UfoObject]
Graphic         = UfoGraphic
Position        = (0, 0, -0.1)
Body            = UfoBody
AngularVelocity = 200

Run this and the ship will have a small amount of spin at the start until the AngularDamping on the ufo body slows it down again.

# Following the UFO with the camera

While we can simply move the ufo around with the keys on a fixed background, it will be a more pleasant experience to have the ufo fixed and have the screen scroll around instead.

This effect can be achieved by parenting the camera to the ufo so that wherever the ufo goes, the camera goes.

Currently, our project is set up so that the viewport has a camera configured to it. But the camera is not available to our code.

We will require the camera to be available in a variable so that it can be parented to the ufo object.

To fix this, in the Init() function, extract the camera from the viewport into a variable by first removing this line:

orxViewport_CreateFromConfig("Viewport");

to:

orxVIEWPORT *viewport = orxViewport_CreateFromConfig("Viewport");
camera = orxViewport_GetCamera(viewport);

And because the camera variable isn't defined, do so at the top of the code:

#include "orx.h"
orxOBJECT *ufo;
orxCAMERA *camera;

Now it is time to parent the camera to the ufo in the init() function using the orxCamera_SetParent function:

ufo = orxObject_CreateFromConfig("UfoObject");
orxCamera_SetParent(camera, ufo);

Compile and Run.

Woah, hang on. That's crazy, the whole screen just rotated around when ufo. And it continues to rotate when hitting the ufo against the walls. See how the camera is a child of the ufo now? Not only does the camera move with the ufo, it rotates with it as well.

We certainly want it to move with the ufo, but it would be nice ignore the rotation from the parent ufo. Add the IgnoreFromParent property to the MainCamera section:

[MainCamera]
FrustumWidth     = 1024
FrustumHeight    = 720
FrustumFar       = 2.0
FrustumNear      = 0.0
Position         = (0.0, 0.0, -1.0)
IgnoreFromParent = rotation

Re-run. That's got it fixed.

Now when you move around, the playfield will appear to scroll rather than it being the ufo that moves. This makes for a more dramatic and interesting effect.

In Part 4, we will give the ufo something to do. The goal is to collect several pickups.

Report Article

## User Feedback

There are no comments to display.

## Create an account

Register a new account

• 0
• 0
• 1
• 1
• 3

• 12
• 9
• 9
• 17
• 21
• ### Similar Content

• Im looking to make an isometric flash game called Super Lands and I need a little help. I just want a flash game that I can play at school with friends through online multiplayer.
The concept is that you create a custom avatar, make a name and bio, then explore a vast series of lands where you can craft, build, and destroy like in Minecraft and Terraria. There would arena events, a large city to trade and role play online, and most importantly there's save data for the players so they don't have to start new each time they get into the browser.

• By ryt
I took a look at this video to see the difference between static and dynamic linking. Basically the author uses __declspec(dllexport) to export a function.
How could we also export classes from the same file? Do we need to put the same keyword before class definition or maybe something else?
• By ryt
Consider the following classes and pInt declaration:
class A { ... }; class B : public A { void function() { int A::*pInt; // use pInt } }; Where does pInt belongs, is it local to B::function() or it's a member of A?
• By ggenije
Important: I am trying to realize in scrtach which is performance very low due to it's "virutal level" scrtach->flashplayer->java...
Also i'm new to this forum so i'm sorry if I missed group (like last time)
Like a title is saying:
I have project ,and I get negative feedback on it because some people need 30 min to complete it (what is the planned time)
but problem is that some people need EVEN 5 hours…(game is incremental/idle/upgrade type so it's important to keep same time ...)
———————————————————————————————————————-
Of course people with slower computer will have less fps so game will be slower for them,
so I have created TimeDelta system for each frame to calculate something to do per second
for example
Update(){move(TimeDelta*speed)}  so that mean it will be moving speed number of pixels(or units) per second so it will be same for almost each user.

But problem is next:
I have to change ySpeed by jumpPower (#PlayerJump in my project)
when any jump button is pressed
then in each frame decrease ySpeed by gravity it is(-10 * TimeDelta)
but when someone have lower fps it will have higher TimeDelta and will fall faster but with same jump it turns out to jump significantly lower that changes core of game
BUT even worse if fps suddenly in moment of jump then timeDelta would be 1 so player will jump much much MUCH higher , then fall much slower because timeDelta changed in meanwhile…(and the point of my game is about upgrading jump not complete game in first fps drop)

—————————————————————————————————————————————————————

Then I got an idea to fix TimeDelta (like in unity for rigibody) so it will be rounded like
if calculated TimeDelta is 0.01834 it will be 0.02 fixed
if weaker computer is using it the TImeDelta will be 0.143 so runded to 0.14 and so on…

I did not manage to realize it… i tried to calculate it before main initialization of game objects
but I'm afraid to fps will drop in moment that is calculating so it will be much diffirent…
I was trying with empty loop(400)(in scrtach even this is taking time) to calculate it but i'm not sure is it right

So is there good way to realize this fixed TimeDelta
I only have timer function to use and time difference between frames

• I've been experimenting with my own n-body simulation for some time and I recently discovered how to optimize it for efficient multithreading and vectorization with the Intel compiler. It did exactly the same thing after making it multithreaded and scaled very well on my ancient i7 3820 (4.3GHz). Then I changed the interleaved xy coordinates to separate arrays for x and y to eliminate the strided loads to improve AVX scaling and copy the coordinates to an interleaved array for OpenTK to render as points. Now the physics is all wrong, the points form clumps that interact with each other but they are unusually dense and accelerate faster than they decelerate causing the clumps to randomly fly off into the distance and after several seconds I get a NaN where 2 points somehow occupy exactly the same x and y float coordinates. This is the C++ DLL:
#include "PPC.h" #include <thread> static const float G = 0.0000001F; const int count = 4096; __declspec(align(64)) float pointsx[count]; __declspec(align(64)) float pointsy[count]; void SetData(float* x, float* y){ memcpy(pointsx, x, count * sizeof(float)); memcpy(pointsy, y, count * sizeof(float)); } void Compute(float* points, float* velx, float* vely, long pcount, float aspect, float zoom) { #pragma omp parallel for for (auto i = 0; i < count; ++i) { auto forcex = 0.0F; auto forcey = 0.0F; for (auto j = 0; j < count; ++j) { if(j == i)continue; const auto distx = pointsx[i] - pointsx[j]; const auto disty = pointsy[i] - pointsy[j]; //if(px != px) continue; //most efficient way to avoid a NaN failure const auto force = G / (distx * distx + disty * disty); forcex += distx * force; forcey += disty * force; } pointsx[i] += velx[i] -= forcex; pointsy[i] += vely[i] -= forcey; if (zoom != 1) { points[i * 2] = pointsx[i] * zoom / aspect; points[i * 2 + 1] = pointsy[i] * zoom; } else { points[i * 2] = pointsx[i] / aspect; points[i * 2 + 1] = pointsy[i]; } /*points[i * 2] = pointsx[i]; points[i * 2 + 1] = pointsy[i];*/ } } This is the relevant part of the C# OpenTK GameWindow:
private void PhysicsLoop(){ while(true){ if(stop){ for(var i = 0; i < pcount; ++i) { velx[i] = vely[i] = 0F; } } if(reset){ reset = false; var r = new Random(); for(var i = 0; i < Startcount; ++i){ do{ pointsx[i] = (float)(r.NextDouble()*2.0F - 1.0F); pointsy[i] = (float)(r.NextDouble()*2.0F - 1.0F); } while(pointsx[i]*pointsx[i] + pointsy[i]*pointsy[i] > 1.0F); velx[i] = vely[i] = 0.0F; } NativeMethods.SetData(pointsx, pointsy); pcount = Startcount; buffersize = (IntPtr)(pcount*8); } are.WaitOne(); NativeMethods.Compute(points0, velx, vely, pcount, aspect, zoom); var pointstemp = points0; points0 = points1; points1 = pointstemp; are1.Set(); } } protected override void OnRenderFrame(FrameEventArgs e){ GL.Clear(ClearBufferMask.ColorBufferBit); GL.EnableVertexAttribArray(0); GL.BindBuffer(BufferTarget.ArrayBuffer, vbo); mre1.Wait(); are1.WaitOne(); GL.BufferData(BufferTarget.ArrayBuffer, buffersize, points1, BufferUsageHint.StaticDraw); are.Set(); GL.VertexAttribPointer(0, 2, VertexAttribPointerType.Float, false, 0, 0); GL.DrawArrays(PrimitiveType.Points, 0, pcount); GL.DisableVertexAttribArray(0); SwapBuffers(); } These are the array declarations:
private const int Startcount = 4096; private readonly float[] pointsx = new float[Startcount]; private readonly float[] pointsy = new float[Startcount]; private float[] points0 = new float[Startcount*2]; private float[] points1 = new float[Startcount*2]; private readonly float[] velx = new float[Startcount]; private readonly float[] vely = new float[Startcount];
Edit 0: It seems that adding 3 zeros to G increases the accuracy of the simulation but I'm at a loss as to why its different without interleaved coordinates. Edit 1: I somehow achieved an 8.3x performance increase with AVX over scalar with the new code above!