Help please

ID:177677
 
Aug 11 2002, 7:49 pm
Does nebody know how to make a game with smooth gameplay? like in Theodis's racing game?
if u could answer that question cleary, or better yet, on the pager, i would be extremely happy.
thanx
DiZzyBonne
Aug 11 2002, 7:53 pm
mob
animate_movement = 0
client
East()
usr.pixel_x += 2
if(usr.pixel_x >= 32)
usr.pixel_x -= 32
usr.Move(EAST)
Aug 11 2002, 8:10 pm
In response to Garthor
Garthor, when i move 32 pixels, it puts me back where i started and it says
runtime error: Cannot execute null.Enter().
proc name: East (/client/East)
source file: help3.dm,9
usr: DiZzyBonne (/mob)
src: DiZzyBonne (/client)
call stack:
DiZzyBonne (/client): East()
Aug 11 2002, 8:12 pm
In response to Garthor
Would't the object move really slowly?
Aug 11 2002, 8:17 pm
In response to BurningIce
also, in the racing game, if u press left or right, it turns u that way. how would u do that. and if u press up, u go the way ur facing. how would u do that too.
Aug 11 2002, 11:44 pm
In response to DiZzyBonne
DiZzyBonne wrote:
also, in the racing game, if u press left or right, it turns u that way. how would u do that. and if u press up, u go the way ur facing. how would u do that too.

Well it just takes a bit of trig and the rotation thing was done with icon arithmatic.

I just have the game store the angle of the mob. When the client.East() and client.West() are called I adjust the angle based on how well the car can turn. Then I have the icon adjusted using the Turn() proc. As for moving in the direction of the angle it takes a bit of trig. You need to use sin() and cos() to break up the speed and angle into x and y components which you add to the mobs position. Then after using the pixel offset vars it makes the car move nice and smoothly. Once BYOND has a client eye offset var I'll be able to make the camera smooth too.
Aug 12 2002, 4:26 am
In response to Theodis
Theodis wrote:
Well it just takes a bit of trig and the rotation thing was done with icon arithmatic.

I just have the game store the angle of the mob. When the client.East() and client.West() are called I adjust the angle based on how well the car can turn. Then I have the icon adjusted using the Turn() proc. As for moving in the direction of the angle it takes a bit of trig. You need to use sin() and cos() to break up the speed and angle into x and y components which you add to the mobs position. Then after using the pixel offset vars it makes the car move nice and smoothly. Once BYOND has a client eye offset var I'll be able to make the camera smooth too.

To expand on Theodis's point I'm gonna provide a short code example:
mob
  var/list/iconset
  // var/angle will be put in atom/movable

  proc/GenerateIcons()
    var/icon/ic=new(icon,icon_state)
    iconset=list(fcopy_rsc(ic))
    for(var/i=1,i<40,++i)
      var/icon/ic2=new(ic)
      ic2.Turn(i*9)
      iconset+=fcopy_rsc(ic2)
  proc/PickIcon()
    if(angle<0) angle+=360
    else if(angle>=360) angle-=360
    icon=iconset[round(angle/9,1)%40+1]

That will generate the icons in 40 different states. Every angle is rounded to the nearest 9°. (Theodis, I understand, uses all 360°. I think you can get even more granular if you're masochistic enough.) If you want to change this, say, to a 5° step, then change the 9's to 5 and the 40's to 72 (i.e., 360/5). The smaller the step, and the more icons you do this with, the more it'll suck bandwidth. With just a little work you can modify this code to make the step size variable--there's no rule that all objects have to have 9° steps when just 15° or 30° will suffice, for example. As a rule I'd try to pick steps that are divisors of 45°.

It's time to talk about conventions: In the code above, 0° points in a certain direction, and all the other angles go around clockwise; that is, 90° is to the right, 270° to the left. In navigation 0° is considered to be due north, so let's stick with that. 0° is north, 90° east, 180° south, and 270° west.

Now, for moving: The direction you move in is determined by the sine and cosine functions. The step, in x, will be sin(angle), and in y will be cos(angle). (This doesn't hold for all coordinate systems, but that's how it works in BYOND.) Try this:
atom/movable
  animate_movement=0  // glitz will look funky when x,y change
  var
    realx;realy       // position, with decimals for precision
    vx=0;vy=0         // velocity (per tick)
    angle=0;vspin=0   // direction and spin (clockwise)

  New()
    ..()
    if(loc) realx=x;realy=y
  Move(newloc)
    .=..()
    if(.) realx=x;realy=y

  // be careful x,y don't go out of bounds
  // then z=0 and you can't get back without using Move()
  proc/Reposition()  // place on map correctly
    x=round(realx,1);y=round(realy,1)
    pixel_x=round((realx-x)*32,1);pixel_y=round((realy-y)*32,1)

  // adjust x,y,angle for velocity and angular velocity
  proc/Update()
    x+=vx;y+=vy;angle+=vspin
    Reposition()

  proc/Accelerate(a)
    vx+=a*sin(angle);vy+=a*cos(angle)
  proc/Turn(t)
    angle+=t
    if(angle<0) angle+=360
    else if(angle>=360) angle-=360
    PickIcon()

mob
  Update()
    ..()
    PickIcon()

This should be enough to get you started.

Notice there's nothing in there for handling the physics of collisions between objects. I'm actually working that out myself right now, with limited success and slow progress. To put in support for that kind of thing, each object is going to need var/mass to indicate its mass. (It also needs I, a variable representing the moment of inertia, used for calculating changes to the spin.)

Lummox JR