On the detection of collisions during game programming
(c) 2005 by YSS, sdD+J., dnc.
------------------------------------------------------


Introduction
------------

Today we'll discuss briefly the detection of collisions 
between MOBs on screen during the process of game 
programming and execution.

First let's introduce collisions and let's think about 
them for a while.  What is a collision?

A collision can be thought of as an interaction between 
two masses in space-time.

It is very important the way we idealize collisions 
during game programming before writing one single line of 
code, just as it is important to know the difference 
between referring to character maps as tiles when writing 
games.  In the process of thought that takes place when 
creating a microprocessor controlled game, there is a BIG 
difference.

The way we focus on the process of two objects colliding 
and the results it implies will reflect greatly on the 
actual collision detection routines we will come up with.  
Actually, the performance of such routines will depend 
greatly on how we picture things in our minds before 
programming.


There is a difference between a mathematician writing 
games, an application's software developer employed to 
write games, an artist who creates with computers and who 
makes games, a professional game maker whose life is 
about making games, a smart child with a dream writing a 
game and a student who MUST use mathematics and write a 
game.  The outcome is different each time.  The gameplay 
reflects this outcome.

Part of that outcome has to do with the way each mind 
focuses on the actual problem of creating the game.

While someone immersed in mathematics may view a screen 
image, a MOB (movable object block) as an area of some 
sort -polygons perhaps- a child isn't likely to think of 
the MOBs this way.

A child may think of the MOB as an actual entity, an 
action figure he has to move around the screen, 
regardless of the technical difficulties involved: that's 
secondary.

A professional game programmer may think of the MOBs as 
subcircuits and an artist isn't likely to think of pixels 
as light representations of digital values.

The same happens when one thinks about writing a 
collision detection routine, however simple it may appear 
to be.


I've seen commercial games fail to attract an audience  
simply because the collision detection routines weren't 
good enough to provide a "playable enough" experience.


From the many different ways to visualize collisions on 
screen and the many different methods to make the 
routines work, the one we choose will affect the output 
greatly.  That's why it is so important to understand 
collisions, maybe not in the physical world, but to 
understand what it is that we really need from our 
collision detection routines on screen and what it is 
that we must get from them while we write them, when we 
test them and when they seem ready to be used.


The bottom line is that the better we're able to 
translate the actual collision process from our thoughts 
into the game in practice without complicating things too 
much, the better the actual gameplay will be -at least as 
far as the collision detection routines go.




YSS
pixelrat@hotmail.com
http://www.oocities.org/yssmlp
///////////////////////////////////////////////////////