Log In  

Hi everybody!

So, for a jam I'm far too unskilled to have considered, I'm putting together a little game where up to four players can pilot tiny ships and defend a fort. The ships can move about, and (eventually) shoot in the direction of a target that can be rotated around the ship by holding a button. It looks like this in practice:

(Enemies and animations forthcoming.)

Right now, I am attempting to optimize the code, because the player inputs eat a LOT of tokens in their current form. I currently have four different sets of inputs, one for each player, and each also moves a target that is specified as its own object (target1 with .x and .y, target2 with .x and .y, etc.). This is obviously no good, given the immense redundancies.

I think one could probably code a generic input function by making each target a property of its ship, using something like this:

function input(p)
  if btn(0,p.c) then p.x=p.x-1 p.targetx=p.targetx-1         --repositions player and target
   if p.x<0 then p.x=0 end                                   --prevents leaving the screen
   if p.targetx<0 then p.targetx=p.x+radius*cos(p.a/360) end
  end
  if btn(1,p.c) then p.x=p.x+1 p.targetx=p.targetx+1         --repositions player and target
   if p.x>120 then p.x=120 end                               --prevents leaving the screen
   if p.targetx>120 then p.targetx=p.x+radius*cos(p.a/360) end
  end
  if btn(2,p.c) then p.y=p.y-1 p.targety=p.targety-1         --repositions player and target
   if p.y<16 then p.y=16 end                                 --prevents moving into sandbar at top of screen
  end
  if btn(3,p.c) then p.y=p.y+1 p.targety=p.targety+1         --repositions player and target
   if p.y>120 then p.y=120 end                               --prevents leaving the screen
   if p.targety>120+radius then p.targety=p.y+radius*sin(p.a/360) end
  end
  if btn(4,p.c) then end                                     --fires bullet (to be implemented)
  if btn(5,p.c) then p.a+=target_speed                       --rotates target
   p.targetx=p.x+radius*cos(p.a/360)
   p.targety=p.y+radius*sin(p.a/360)
   if p.a>360 then p.a=0                                     --resets target angle if needed
   elseif p.a<0 then p.a=360
   end
  end
end

Basically, as long as we specify the controller (c) associated with each player (p), we can use one function to dictate all player inputs. So, for each player, we have to put together a simple table of attributes.

And here is where my problem occurs: those stupid little targets.

Here's what I have tried to use for the first player's attribute table:

 p1={
   exist=false,
   dead=false,
   idle=true,
   x=50,
   y=50,
   a=180,
   idlesprite=3,
   movesprite=7,
   w=8,
   h=8,
   score=0,
   lives=3,
   c=0,
   targetx=p1.x+radius*cos(p1.a/360),  --PICO-8 doesn't like this line.
   targety=p1.y+radius*sin(p1.a/360),  --Or this one.
   targetsprite=16
   }

It seems PICO-8 doesn't accept putting p1.x, p1.y, and p1.a in those trig functions for p1.targetx and p1.targety. It raises an error, saying that they indicate an attempt to index a nil value. I guess I could just throw in a raw number for them? But I kind of need those variables, I think, since the location of the player's target must depend on the location of the player's ship.

TL;DR: A table isn't working like my noob brain would expect, and I have three questions:

  • Why are p1.x, p1.y, and p1.a nil values, if I already provide values for them in the table?
  • How else might I define targetx and targety, such that they remain properties of p1?
  • If the method I've proposed is stupid, what might you suggest as a workaround?
P#73758 2020-03-21 18:53

Nevermind! I managed to make it work by writing out the tables in this form:

p1={}
 p1.x=
 p1.y=
 ...

Anyway, the input optimization thingy worked, so if any of you have need of its code, let me know!

Thanks for reading.

P#74115 2020-03-22 16:21

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-29 13:07:08 | 0.005s | Q:7